Only that lock-free (or wait free, or even obstruction-free) datastructures aren't exactly trivial to implement correctly either. Besides often having architectural impact (Uh, Oh, I now need to declare quiescent periods?), they're extremely hard to debug, and there's even less automated verification than for locking.
there are many design alternatives to locking. Lock-free synchronization is one of them, but queueing is another. The best alternative is to simplify your control flow so that you don't need as much synchronization.
I have never seen lock-free synchronization touted as a simpler alternative to locking. (And I do lock-free synchronization.) Avoiding synchronization as much as possible is a good principle - one which I use often, and I actually contend is the only way to write scalable code. But someone always need to eventually synchronize. Even if it's not your code explicitly, somewhere, your code will have to rely on code someone else wrote that synchronizes. This article is aimed to those people.
