> Main point of real threads is that the are executed simultaneously on different cores

Sorry, that's about as far from truth as you can get. Threads were a thing way before multicore was available. Windows got them since Win95/NT4.0, and these didn't support multicore, nor did most of OpenVMS machines where NT thread model originated run multicore (were there any multicore VAXen at all). The two main points for threads back then was to simplify concurrent IO and to be able to run a background computation without hanging the UI. Unix was different because it was initially oriented towards timesharing aka. running a single program for user, so threads were seen as redundant complexity (as were async IO - so even today "I want to run something yet be able get more user input at any time" can sometimes be a PITA).

And year, not everything needs scalability. Scalability is actually actively harmful for everything that's not a server. E. g. UI needs to be responsive - but that doesn't necessary mean "run on multiple cores", rather "being able to preempt low-priority stuff". And usually you don't want to deal with multicore synchronization.

MCUs rarely have multiple cores. Yet multi-threading is ubiquitous, and on most RTOSes threads are much closer to "green threads" than Windows ones. Through as I keep screaming in every coroutine thread, I really wish C stackless coroutines were a thing, you can't afford a stack for everything.

There are more to this world than the boring AWS crud.