we never saw the need to use the other cores. the CPU is a few million times faster than the cycles, if there is a problem it's a HW IO or blocking driver. even with normal 500Hz ECU's you can always upgrade the CPU freq to run faster, than needing more cores. even better would be to use better drivers with zero copy and MMU access.
it's nice that threading got better recently in embedded Realtime OS's, HW always gets better, but certainly drivers not and SW not. and developers even less. maybe they think rust will help, but then they should chose a proper concurrency-safe system. certainly not rust, which only lies about it.
also this thing is only simulation verified, not formally verified.
I hate to break it to you, but hardware is basically always broken, and it's all "fixed" in software (especially in embedded, where some vendors don't even bother with steppings to fix errata).
It depends on what you consider to be absolute requirements for proper concurrency safety of course, and how much of the hardware is allowed to fail before it starts impacting the software.
I've also seen arrangements where the dual-cores have separate memory spaces, and one core acts like a safety processor/monitor while the other is the main compute module.
1: examples of CPU intensive stuff include active damping, active aero (spoilers), active rear steering, steer by wire, etc. You may think these things are irrelevant w.r.t. an engine ECU, but if the engine ECU is responsible for producing torque, then systems like traction control, stability control and etc are all directly related to torque production