Correct. man 7 pthreads states:
In NPTL, thread synchronization primitives (mutexes, thread joining, and so on) are implemented using the Linux futex(2) system call.
A futex is a mutex that only does a system call if there is contention; you can google it.
True, there are scenarios when you might prefer to spin, but they're pretty specialized.
My blog post was quite clear that I'm talking about futexes
No, you never mention the word "futex."
When somebody says "mutex", you have to assume they already mean "futex".
I don't think that's a valid generalization at all.
What systems have mutexes that aren't built like futexes?
Especially given he was complaining about syscall costs . . . which are nonexistent with futexes . . .
At any rate, you've definitely overstated the case against mutexes in this post. At most, the advice should have been "avoid designs that will suffer from a lot of contention" like locking with lots of shared mutable state. It really has nothing to do with threads-vs-processes as you've made it out to do.
Affinity is definitely valuable, but I don't think you should need to disable interrupts for most applications. I'm not even sure if it is generally possible, since interrupts are sometimes used to swap pages or notify the kernel that a page isn't mapped or that a blocked resource is now available. The reason affinity is valuable is not because of kernel interactions. It's because of NUMA and cpu cache swapping. Affinity can prevent thread migration, which is expensive mainly because data also has to be migrated or else accessed in a less efficient manner. Likewise, make sure that if you dispatch an asynchronous call, the handler runs on the same core you sent the call from.
Finally, it's a common fallacy in these kinds of posts to act as if threads can't be used to do shared-little or shared-nothing-style multi-programming. They often aren't, but there's nothing that prevents it.