Can you elaborate on what you think real-time processing really means?
Real-time doesn't mean "fast", or "maximum throughput". In fact, strict real-time goes against maximum throughput.
It means that there is predictable timing, a guaranteed point in time by which a certain piece of work is done. The actual amount of work is strictly limited.
Real-time systems in the narrow sense (stricter than our music systems) require special OSes and special programming techniques that are incompatible with our (relatively) complex algorithms. For example, you would be unable to use dynamic memory allocation. But music system don't even aim for that. The closest we get is the PREEMPT_RT preemption mode in Linux-6.12 which gives you a real-time OS kernel (at the expense of throughput and general speed), but even then DAWs are very far from real-time programs.
Anyway, E-cores are actually
more suitable for real-time programming since they don't clock as high and hence it is more predictable what amount of work they get done in what amount of time.
When it comes to DAWs on heterogenous cores CPUs it makes no sense to exclude the slower cores since the processes will migrate between cores anyway, and should be allowed to migrate to and from the E-cores as well. I know that not all DAWs let the OS scheduler do this properly, but there is light at the end of the tunnel with more and more DAWs seeing the light and just let the OS and the hardware do their jobs without misguided attempts to help.
The big surprise, as mentioned, is the non-E-core policy of Apple's own DAW. I think that must be the result of some misguided corporate order to leave the E-cores free for background tasks. In any case, I expect this to fall soon. It makes no sense.