1)

Yes, but then you need to manage IO thread affinity, this isn't commonly done. Also you need to manage what is running on which NUMA node as often on 2 node systems 1 is almost never interrupted except for cross CPU conversation.

Facebook moved to Single Socket Xeon-D's rather then bake task affinity to their HHVM run time. So yeah, people still screw this up a lot.

2)

The main answer to concurrency these days is to just swap thread stacks in userland when ever something blocks. Yeah this works fine, but it's no different then what the kernel does for you. The stack is just smaller, the swapping is baked into the user land program. So you end up breaking most debuggers, and your C-FFI gets very slow.

This isn't any faster then what the kernel is doing. It's just the language run-time limits stack size so the swapping happens faster. Setting smaller stack sizes and using Thread Groups yields similar performance.

Most people have a single, important foreground app which is the only one they care about latency of. The others are ticking over in the background, but because they don't have window focus the user doesn't care about their responsiveness so much.