In my experience the use of a product backlog does not lead to team alignment. The reasons are:
it's tedious to read. The usual way to present written information is as a narrative, where text further down builds on the text that preceeds it. Product backlogs are different. Because stories are meant to be self-contained they are repetitive, and there is no natural flow leading from one story to the other. Moreover, the reader has to open and close the stories to read them. All of this makes reading backlog stories unpleasant and unrewarding.
it lacks structure. Maybe the top stories will be ordered, but the rest will have an almost random order. That rest will contain both interesting and important stories and quick braindumps that are basically noise. And again, since the stories are meant to be self-contained, it's hard to see how they are related. It's like trying to understand a picture by looking at one puzzle piece at the time, and having to guess along the way how the pieces fit together.
it lacks a user perspective. While it's usually possible to imagine how a story helps the user to achieve their goals, it's hard to reconstruct an entire user workflow from reading backlog stories. And when it comes to workflows, the devil is in the details. Workflows tends to change in important ways when you try to get the details right. Figuring these out sooner rather then later helps to align the team on the development plan.
As a result, people will not want to read the backlog, and when they do, they will struggle to obtain an impression of what the team will be working on in the next few months, and where the product will be. Usually, documents that describe the short and medium term plans exist alongside the backlog, but it tends to be unclear how accurate and realistic these plans are, and how they fit together with the backlog.
In the end, it often happens that the actual plan exists mostly in the heads of the team-members, and is communicated by talking. This reduces transparency about the tradeoffs that are made between the different options for improving the product. When information about possible next steps is scattered then weighing the options quickly becomes complex and overwhelming. As a result, nobody will feel responsible for doing this important work, and when it's time to do the sprint planning, some pragmatic ad-hoc choices will be made. This situation leads to poor planning choices. Moreover, the lack of accountability for deciding the plan means that the team will not be able to learn from past planning mistakes.