"People who're knowledgeable say most users don't need hard real-time."
The ECU in your car does need hard real-time. (Image a misfire at motorway speeds.)
The CU in your robot does need hard real-time. (The robot arm hits something as it wasn't commanded to stop in time.)
The FCU/ECU in your plane (commercial or military) does need hard real-time.
The CU in your modern train (elevation or suspension) does need hard real-time. (The maglev could smash into the track ripping up miles of it, killing passengers.)
The FCU in your spacecraft (at least on take-off and landing) does need hard real-time. (Only ever one missed instruction from a RUD.)
One advantage of hard real-time in VxWorks is that you can run all of your critical tasks individually separated in time and space from all of the other tasks running at lesser criticality. Say for a car, the ECU could become part of a single multicore system where the rest of the car systems (probably not the entertainment) run on the other cores. So one control unit for the car rather than 10 or 11. In avionics where weight is a real issue then this federated systems approach is even more critical.
For medical e.g. MRI or nuclear, for instance, you can claim that soft real-time is applicable, but I for one would rather have guaranteed responses, rather than a best effort of software. (We have all experienced the temporary hang of Windows or Linux at one time or another.)
"If you really need hard real-time you can always alter the kernel and handle the interrupts yourself. That's as hard real-time as you can get, better even than VxWorks."
But in doing so you are cutting yourself off from the rest of the generic OS infrastructure, modularity and other system wide aspects. Yes, that is fine in a tiny closed control loop, but not as part of a larger federated system.
I have used VxWorks, because you did, but there are other real-time OS out there that I have used, and written drivers for. But none have a better pedigree and ease of working with than VxWorks.
I could bore you for hours on the subject of multicore redundancy ...
[BTW - the first non-Linux OS to support RISC-V was VxWorks, and that was [secret|many] years ago.]