I think my current role is a really great example of the good and bad things about specialization. I work in a large organization with a big engineering division that has many specialists. They put out stable, reliable and massive projects pretty reliably, but they are relatively slow and full of bureaucracy. There are people who are bottlenecks because they're the specialist in X. There are delays because specialist team X doesn't know what specialist team Y is going to be able to do. Because they're very specialist oriented, getting anything done takes coordination between a lot of different people. But because they have lots of specialists and bureaucracy, they do have a lot of expertise and rigor.

My role basically exists explicitly to counteract that. I am a generalist who works independently of that division, directly under the executive leadership. There is a very broad range of topics that I have professional level experience and abilities in. I can sit with artists and talk their language. I can sit with lawyers and talk their language. I can sit with cloud architects and talk their language. I can sit with devs and talk their language. Etc. And if any of these people is too busy or is on vacation, I can step in, understand what they were doing and fix problems. Because of that, I get pulled in to save the day from the specialists in mainly two cases: (1) when something needs to be done very fast or (2) when a project is lost in bureaucracy because it requires the coordination across too many specialties. There are times I've made something in a week that the specialist organization took many months to do. There are times that I've taken a project that got lost in bureaucracy for years and banged in out in a year because I could meet with every single stakeholder understanding exactly what they need, what they are doing, etc. and because if they cannot do it I can either do it myself or articulate clearly to managers or contractors exactly what is needed. So, me being a generalist has been super valuable and gotten us out of some big jams.

As the generalist, I'm the get-it-done guy and will not stop for any reason, whereas the specialist division is more of a "stay in your lane" people who can get tripped up because of that. That all said, notice how both exist and my leadership isn't looking to eliminate either. It's not that everything goes to people like me because the generalist way is best. It's not that everything goes to the engineering division because their way is best. It's a tradeoff and it's an active choice as to whether certain jobs go to me or them or whether we work together on it.

To put all of that into specifics... A specialist oriented team have some potential disadvantages:

1. It may require a bigger overall team to have slots for each kind of specialist.
2. It may create more waste. If you have x units of database specialist time available per month, but you only have x/2 units of work for them to do this month, then they may be twiddling their thumbs if they aren't competent in other kinds of tasks that you can assign them.
3. It may make the organization less adaptable to changing needs. Over the years, as technology and products evolve, it's not that unthinkable that the kinds of tasks your devs need to specialize in might change a lot. For example, if you move more toward a cloud product after having made standalone applications for a while, the proportion of specialties you need might change.
4. It creates more communication and management overhead to have to manage all of these different authorities and routing tasks back and forth at the boundaries of specialties and the communication and scheduling delays that come from that.
5. Maybe as a combination of 3 and 4, the way you define your list of specialties can create a lot of bureaucracy and limitations in workflow. For example, in my previous job, I was an engineer who could do decent art and my teammate was an artist who could do decent code. We had other specialists on the team too but that's the relevant part. Because we were treated as specialists, there would be bottlenecks when one of us was backed up and the other was waiting. Those bottlenecks could have been resolved if we were looked at as generalists with strengths and weaknesses who could each take on most tasks. But because he was "the art guy" and I was "the code guy", the workflow sometimes suffered. (That said, there were obviously benefits as well. Because he didn't touch the code, it was probably a lot more robust. Because I didn't touch the art, it was probably a bit prettier.)

Meanwhile, having specialists can have advantages like consistency, depth of knowledge and even saved efficiency that comes from a person doing the same kind of work every day rather than needing to "get back into it" and keep changing hats.