MISLEADING / DANGEROUS
In the beginning, the authors claim that the goal of their concept is to maximize speed. Later on, they mention that actually, their focus is first of all on the speed of change within teams. And this is exactly the optimization goal of the entire concept. However, this is not made clear from the very beginning and is hidden deeply inside - that is misleading.
Customer value is a result of work done in cross-component flows. However, three out of four team types offered by Team Topologies are de facto component-centric. Hence, customer value would have to pass through more than one of such teams.
Here is one of several good points from the book: "Local optimizations help the teams directly involved, but they don’t necessarily help improve the overall delivery of value to customers." So, if you use those three component-centric team types, you will optimize for their internal flows which will not necessarily help improve your real customer-value flow. Moreover, from the Systems Thinking we know, that with considerable probability local optimizations sub-optimize the whole.
There's a single place within the whole book, where you can find the confirmation: "Generally speaking, we need to optimize for fast flow, so stream-aligned teams are preferred." This can be easily overlooked or forgotten behind numerous considerations of other component-centric team types.
Moreover, another claim is that "Team Topologies takes a humanistic approach to building software systems while setting up organizations for strategic adaptability."
Yet, it also contains one of the most dangerous points for Adaptiveness: "Every part of the software system needs to be owned by exactly one team."
This approach does not take into account the worldwide successful experience of applying the shared cross-team code ownership with respective adaptation of Structures, Processes, Rewards Systems, and People practices. As a result, this constrains the concept offered by Team Topologies to reach (by using only one out of four team types) only halfway to the true potential of Adaptiveness.
Finally, even concerning Organizational Adaptiveness, the book clearly and correctly stands for long-living teams and suggests team changes not more often than once a year or so. In other words, when you discover the teams were assigned to components wrongly, you will have to choose between waiting with lower speed or sacrificing the team's effectiveness with (again) lower speed.
A more detailed explanation can be found here: How Adaptive are Team Topologies?