Sure, developers should be mindful of all of these things. But if one person or team spends a lot of effort creating solid internal tools, and then they all get fired, you’ve lost a very significant amount of internal knowledge. Then who maintains the tools and updates them as the product changes? Or as industry best practices improve, as is often the case with security?

If you get to the point of having a performance or security team, you realize your org is big enough you need a couple people focusing on it full time (and their role is often helping other developers implement best practices.) By ditching them, you’re acknowledging literally that you’d like to focus less on that area in the future. As a result, product teams will do their best, but it’s impossible for every dev to be up to date on every best practice for every topic in web development. So you won’t do as well.

Maybe that’s ok as a small startup, but when your audience is incredibly large and you operate at scale, it’s not reasonable to have subpar security, performance, accessibility, etc. If you are subpar in these areas, you loose money because your audience is large enough that many are impacted.

I wasn't recommending that they all be fired. Ideally some number of them would be redistributed across other teams. What is often inefficient is keeping a large team around that has largely fulfilled their goals.

Also performance is too large an area to make it a single team. It is better to have a database expert guild (or team) that other teams can consult for performance and other engineering quality issues and similarly for other performance sensitive areas. I can't speak for security but I imagine that each area should have experts that cover security for that area.

Perhaps others like working cleaning up poorly written non-performant designs and code but I prefer starting earlier in the process and building it into the engineering culture.

Edit: I think it's actually easier to have a performance/security team at a medium scale of growth. At small scale they would be in the product dev teams or known by name by all teams. At large scale I don't think they can't cover the surface area/volume produced by all the teams. So it should be more effective to develop mechanisms/processes and culture.