The main problem with specializing in this way is that it presumes that "frontend" and "backend" are the correct criteria to start specializing on, and that the

The main problem with specializing in this way is that it presumes that "frontend" and "backend" are the correct criteria to start specializing on, and that they're equally valuable. For many applications this is simply not the case; usually one is more valuable than the other, and if specialization is necessary it needs to start within one of those two categories instead of between them. A secondary problem is that any time you have an interface and people who can't clearly understand what happens on both sides of it, you end up having integration problems. And meetings to discuss the problems. And proposals to solve the problems. And disagreement on who should solve the problems. And future arguments if the solutions are wrong. "Communicate with an appropriate formalism" is the probably the hardest part of software; why would you introduce that if you don't actually have to?