1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is.
At the moment, it sounds like you're simply "adding threads" to the language and worrying about how to make it correct and performant later. In particular:
if two tasks try to access a variable concurrently it gets marked atomic and they contend for access.
I agree that atomic variables won't solve everything, but working on a solution for the synchronisation problem is my next goal.
Plus, making all variables atomic is the sort of thing that's likely to make a multithreaded program perform worse than its singlethreaded counterpart, which makes it even more important to actually test performance on more realistic programs and see if you're gaining anything or not.
So at the moment, you're asking programmers to consider switching from a singlethreaded environment to a brand new multithreaded environment that has no solution for the synchronisation problem and no evidence it improves real-world performance, and seemingly no plan for resolving those issues.
That's probably why people aren't taken you seriously.
2) The simplicity and robustness of the single event loop is a huge advantage.
Unless you can somehow retain that safety, anyone who might want to switch to a multithreaded node.js would probably be better off switching to a language like Go that's designed from the ground up for multithreaded applications.
P.S. What would convince me to try switching to a multithreaded node.js implementation?
Once you've done that, I think you'll see people much more interested in this idea.