Well, the thing is there are many organizations that live without CD/D (delivery/deployment) and still can release critical fixes quickly. CD does make things easier, but it is not a necessary condition. Let's go through your line of reasoning:

>> a proper support process where critical fixes can be delivered within hours or minutes.

>That the decision to go live is based on criteria and circumstances implies that there are criteria and circumstances that make a release ineligible to go live at those times.

Indeed: you normally do not release the code that is not ready and you do not release the code that will alter the business process before business users are ready to accept the change. It does not mean that it is impossible to deliver a critical fix in such circumstances. Let's look at the delivery process first to understand, if there's really any contradiction.

In a well organized process you have branches and you probably use pull requests to deliver the code to the main branch. This branch does not have to be the same as the branch of the last released code, meaning that you can actually work in both branches. The release cycle on the main branch can be long if your company can manage the complexity of bigger projects. However, if there's a critical bug found, you can develop the fix on the production code branch, then release it quickly and merge the changes to main. The fact that you normally do not push changes as fast as possible to production means that you do not have continuous delivery, but it does not mean that you cannot have automated deployment or even continuous deployment (which would be in this case triggered by a merge to designated branch after automated tests on certain branches are passed).

Now, how about continuous deployment? It appears, you can actually have continuous delivery or automated deployment, but not continuous deployment. For continuous delivery it is sufficient to produce quickly build artifacts via CI, but the way they are released can be really different and may not involve deployment by merge. I worked in an organization where production system was physically separated from delivery pipeline and artifacts had to be copied to a flash drive. We could still produce a change and get it live within 10-15 minutes, because the manual process was actually well-thought and optimized to reduce human errors. We had releases almost on daily basis and we had few times when we actually delivered changes very fast (once it involved a rollback for a complicated $100M transaction through 20 systems that went through because of a missing validation requirement). You may even have a fully automated deployment triggered by one click: the only difference with continuous deployment will be that it's not done once the build is green.

To sum up, CD (continuous delivery) is not the same as CD (continuous deployment) and you can have just one of them or none, still having the automated deployment process. Or not having it, but still being able to deliver critical fixes quickly and with minimal risks.
I do not know, what is the process at SpaceX, but the fact that they did fast rollout does not mean they have CD in either sense or it even makes sense for them. It's better to ask their team. :)