Founded argument to have no sandbox CI/CD?
A CI/CD system is, after all, just another software product/system. Regular upgrades and at least some changes in the plugin installations could be treated as changes of the software product itself. 

I see no founded reason for which such software product can't also use as part of its own development process a CI/CD solution. Maybe even itself - the most recent production version, for example - if it's flexible enough (I'm still investigating such possibility for the CI system I'm working on).

Now, a CI/CD system deployed/actively used in a certain software development project is effectively a software product deployed in a specific environment. 

Changes to the configurations of the CI/CD system aren't actually software changes, they're changes of the environment in which the software system is deployed. These are trickier to address in a CI/CD pipeline. Some even impossible. You'd have to replicate the environment as close as possible. But it's unlikely you'll be able to do that at 100% - just like no dev/QA/etc environment is exactly as the production one.

Some environment changes could be tested in a CI/CD pipeline. For example changes to a test script: both the old and the new versions can be executed as parallel pipeline jobs with the same set of artifacts for a period of time, long enough to determine the test quality and stability before making the new version the official one and retiring the old one.

Finally, don't forget that most CI systems are reactive: they detect breakages, but human action is required to identify the culprit and/or make repairs before the development process can be resumed. Applying such CI system to an actively used CI/CD system one would allow the show-stopper problems you mention. Only a non-blocking CI system can completely prevent them (disclaimer: I'm the founder of the company owning the referenced page and offering such system).