Concurrency, as they say, is a bitch. I would hate to program against that model.
The best model I've found so far is cooperative multithreading, that is, coroutines that explicitly yield control, combined with well-isolated worker threads and a rendezvous mechanism for passing parameters and getting results back. I can write code all day long in this model and not run into very hard to find concurrency issues . . . or at least, not as many. I've written a ton of code in the "every thread for itself, have fun with locking" universe, and man, life is just too short for that stuff.
Naturally you run out of processor headroom in this model because you're essentially single-threaded; message passing between processes and running multiple services, one in each process, is one good approach to scaling. Often you can scale out to the network, too, and with 1K cores you need start worrying about the blast radius of your services when things eventually go sideways so getting off the box is a good idea. And things will go sideways.
I can see a thousand cores being useful for embarrassingly parallel things, like classic graphics algorithms where you're doing mostly SIMD with a few variations. But I can't imagine wrangling a zillion cores to do "random logic" type applications where you have to use traditional low-level synchronization primitives. See above: life is short.
Feel free to color me a dinosaur. I've only got another 20 years of my career to figure this out :-)