Indeed, IME small teams are not "better". It depends. If one is on a research team and has all the skills needed, then the smaller the team the better.

But if one is doing engineering, more people can parallelize a lot of things.

But there is a point of diminishing returns.

And I think a key factor involves leadership: how many people can the team lead stay in touch with? IME the most effective teams are those that have a team lead who knows what everyone is working on, how they are approaching it, and what challenges they have. That's hard to do if there are more than, say, 15 people.

Also, relying on people to self organize is nonsense. They don't do a good job of that generally. For most groups of people, there really needs to be someone who glues everything together and stays on top of the big picture and knows how everything is progressing: the other team members are too focused on getting something done to have cognitive space to always be thinking of the big picture.

This was one of the highest performing teams I ever had a hand in setting up. I think there were someone in the range of 12-15 people: https://scaledmarkets.blogspot.com/2017/01/inserting-devops-into-not-very-agile.html

Also, yes, product level features should be prioritized. Teams should not be prioritizing. The product is what matters - not the team.

Regarding T-shaped people, there are aspects of that not included in the model. In the case study I cited above, everyone received all the same training: business analysts as well as programmers received instruction on how to write Cucumber-based automated tests. Everyone received a day-long class on setting up their own OpenShift cluster on their laptop. That has a very powerful side effect: everyone understood what was being done. That breadth of awareness created a very strong communication between the analysts and programmers.