Because every operation is big enough to have a distinct QA environment.

Not to mention I would question the idea that developers should be distinctly detatched from quality, uat, and operations.

It's a very old way of thinking, and while sometimes it might be the best method for the environment ( highly sensitive compartmentalized operations) that division more often than not results in poorer outcomes.

The idea that developers should not be doing their own QA with real world data prior to releasing to a separate qa/uat team is half of the problem with half of development these days. It often results in far more round trips of develop-> test -> qa -> defect found go to 1.

"Developers develop, qa quality assures, and operations operates" is why things always end up broken, defective, over budget, and underpowered. Aside from situations where it is necessary, blended operations, more broadly granulated over areas of expertise typically result in far better outcomes.

Perhaps you work in a sphere where those environments are required, but few people really do, and so speaking with a sense of absolutism as you have really doesn't further the conversation in a constructive way