I always thought the traditional distinguishing terms here were "hard realtime" (e.g. control software) versus "soft realtime" (e.g. games). Are those not widely used any more?
They are used, but hard vs. soft realtime is tangential to the broader discussion here.
If we stick with the video game example, it has a real time goal: having frames displayed at the target framerate. The "soft" aspect comes from the fact it's tolerable for a game to fail some deadlines. It's certainly undesirable, but a few minutes of frame-y gameplay is not game-breaking.
Depending on the particular system, there will be tolerances of how frequently and in which ways a realtime deadline can be missed without constituting an overall failure of the system.
Hard, Firm, and Soft real-time are all classifications in real-time computing. They are measurements of how detrimental it is to the system if they miss a deadline. Control systems can still be soft real-time.
And those terms may be used not to refer to the system as a whole, but particular tasks within it. Hard constraints on tasks that can never miss a (often nanosecond resolution) time point, firm real-time that can't be missed but which can be delayed, soft real time that can be missed (but only a certain number or percentage of times, or can't be missed twice in a row, etc). Different systems and teams may use those categories differently. For example, the AGC alarms that nearly caused the Apollo 11 Eagle landing to abort were for tasks in the last category, so they were able to continue. There were other tasks on that same real-time system for which missing the timing would have required an abort (or triggered a lot of very loud noises followed by silence).
