Nexus Product Backlog Refinement
In Nexus Guide Chapter Nexus Process Flow/Refine the Product Backlog is written: "..and the team likely to do the work should be identified as early as possible."
Maybe a Product Backlog item needs special domain or technical knowledge which fits best to a special team but this could lead teams to become less flexible. So I don't think it is the purpose to identify the team which knows best/is fastest etc.
Or it is just a part of the Definition of Ready that when it is possible to nominate a likely team you have good chances that the dependencies are removed/minimized? As I understand the Nexus Product Backlog Refinement is about understanding the business goal and minimizing dependencies. Do you think "identifying the likely team" as a part of the Definition of Ready makes sense? New dependencies can emerge in Nexus Sprint Planning of course but there shouldn't be hopefully big surprises which could a re-slicing make necessary.
I wonder how this identification of the likely team works in practice as it should be a pull-based and not assignment-based approach.
Identifying a likely team by domain knowledge may well be sub-optimal, since that specialization could be a wasteful constraint.
On the other hand the over-generalization of team skills can also be a wasteful exercise. If work can be organized so that this waste is avoided, by directing it to a certain feature team in a timely manner, then that isn't unreasonable.
Nevertheless, you make a good analysis. The essential reason for organizing work by prospective team should indeed be to minimize dependencies. Remember that this includes dependencies upon any specialists.
Your concern about the potential implication for "pull" is insightful and valid. A couple of years ago I blogged about this matter: https://dzone.com/articles/ordering-a-product-backlog-to-minimize-development