Combining the user workflows and implementation outline in one document gives the reader a complete high-level picture. If the entire development team understands and agrees on a milestone, then chances are good that they are aligned. The milestone will not describe all the details, and therefore people may have slightly divergent ideas, but they will agree on the main points. If during development some major changes to the plan occur then the milestone description will become the common source of truth for the new plan. People can comment on the milestone and propose changes, which leads to a discussion and eventually to an updated milestone description. Ideally, these changes will not mean that the goal of an ongoing sprint also changes, just that it's achieved in a somewhat different way.
The technical product roadmap invites you to think things through on paper (I believe the value of this is often underestimated). This is less agile than what Scrum or Kanban advocates, but it does still leave room for figuring things out during development. In fact, this is necessary to keep the milestone descriptions concise and readable. Interweaving the description of the user experience with key implementation details helps to ensure that the implementation choices are grounded in the user requirements. This is important because surprisingly often the implementation is driven by what is technically possible rather than following the most effective way to create the user experience.
The inclusion of a glossary helps a lot in creating a common understanding in the team about the main domain and implementation concepts. Creating the glossary will be a process of exploration and discussion that can clarify a lot of misunderstandings in the team.
Since the technical product roadmap is the single source of truth for the product development priorities, it creates transparency about the concrete plan for the next months. Of course, the number of options for improving the product can still be daunting, but at least the current plan (even when it's constantly being debated and updated) is visible. It's very important though that the milestones are concise and interesting to read so that people are inclined to consult the roadmap often. When this is the case it fosters healthy discussion and good decision making because any insertion of new work into the roadmap immediately makes it clear how this will delay other work. If the roadmap is not an attractive document, it will be ignored and useless.
I personally do not attach deadlines to milestones. Rather than as a planning tool I use these roadmaps as a communication tool, one that allows the team to be on the same page regarding priorities, features and implementation. However, I do insert important dates (e.g. a fixed release date) into the roadmap so that it becomes clear which milestones should be finished before these dates.
It's useful to combine the roadmap with Scrum or Kanban, where user stories are derived from the roadmap. The roadmap leaves out steps that are not interesting for readers who want to understand the high-level plan, but a sprint planning needs to be a complete description of the required work and should definitely include stories for them.
The biggest drawback of a technical product roadmap is that it requires you to read. The amount of text is not overwhelming, but you can expect to need 5 to 10 minutes to read through a milestone. When the roadmap is used correctly, it will become a living document that people return to on a daily basis. In that light the required time investment is modest, but still the fact that the roadmap is entirely text-based can be off-putting to people.
Another potential drawback is that creating a good roadmap requires skill. It's especially an art to choose the right level of detail.
A roadmap works well when there are features that need to be developed, because these features can be described as a workflow, and by understanding and discussing workflows the team can create a shared product vision. The situation is different when most of the work consists of bug fixes and chores, because then the milestones will not have an overarching goal. In this case the roadmap is still useful for clarifying the priorities in fixing the issues, but it will in fact look much like a product backlog.
An alternative apprach that is less text-based is to use Story Mapping. Since this approach makes it easy to layout the different stories in development iterations it can give a lot of insight about the product development priorities. On the other hand, it provides a more loose description of user workflows and therefore gives fewer guarantees about achieving team alignment on the development plan.