Viking; Your understanding of processors is stuck back in the mainfraim era, it doesn't mater in the slightest whether threads can be run simultaneously on one core or multiple cores, it's about whether the OS is capable of utilising them, and RISC OS isn't.
RISC OS has it's roots back in Arthur which in turn was a warmed up version of the BBC B's MOS, basically a single program running at any one time, and a single state for all interaction with the OS. The only change was allow programs to yield to others on request at certain points - the Wimp_Poll and co-operative multi-tasking.
The crucial thing to take any advantage of multi threads/cores is to give each application it's own OS context so the OS can simultaneously deal with more than one application, no matter what it is doing. This also allows both pre-emptive multi-tasking and multi-processing across cores. With say a 90% rewrite of the OS and all application modules, this could be achieved.
However RISC OS is further hampered by the fundamental assumption that things like WIMP messages happen in a certain order, and any other events being received will stop most applications from handling the messages properly. You have a choice of either maintaining a compatibility behaviour and still having everything freeze if one task isn't responding, or accept a lot of things will no longer work.
As for your Wimp_Poll idea, I assume you are suggesting that the handler for each type of event be run in a separate thread, which has little or no advantage, and would be guaranteed to break everything.