For large complex software systems every team member can't be an expert on everything. That's why within the overall program you set up separate small agile feature teams composed of team members who each bring some specialized skills and experience. Plus you should also layer on a matrix of component stewards who help maintain technical integrity for individual components. For a detailed explanation of how that works please see Ken Rubin's presentation "Scaling with Feature vs. Component Teams". http://www.innolution.com/resources/presentations/svaln-2015...
No one ever claimed that a feature team organization is a silver bullet. But if implemented right it will usually deliver at least a minor boost.
In my view optimizing productivity isn't necessarily mutually exclusive with other things you're trying to achieve. If productivity is very low then most other measures will tend to fall too though that may lag. The problem is that productivity tends to have poor visibility and is difficult to measure.
What I object to with all my heart is the "feature team" as the assembly line model of software "features". I.e. the software factory where features come in one end, get assigned to a random team, and product gets delivered on the other end. This model results in low quality, expensive, bloatware at best. It may or may not at any given time make some money. It's also not the model used, AFAIK, in most successful software companies.
In a large software system you can't expect any individual to be as effective working in any area of the system. So you're winning on the blocking front but you're losing on the productivity front as people ramp in on different pieces and you're also potentially losing a sense of ownership from the developers and instead giving them a sense they're cogs in a machine...
To me a better compromise is to ensure you have enough of a backlog that you can always pick something that is the right combination of expertise/interest/lock-free at any given time. If you plan properly and you have sized your teams properly things should move along better than trying to get everyone to work everywhere on some random feature. That's not to say you can't occasionally do that if something important comes along but to me feature teams in large scale software is to be avoided. [EDIT: realizing this is maybe too strong of a statement, a team can definitely work across multiple pieces and will ideally implement complete features, but those features need to be a match to the capabilities of the team as opposed to just looking a "feature team" as some sort of unit of production for any random feature]
There's another part to this which is that it can be difficult to see the inter-dependencies between features. So modelling your software development as a bunch of teams that can just pull the next feature from the queue and work on it may actually not solve the locking problem at all but create more subtle dependencies and less efficiency.