Spin locks are discouraged in FreeBSD kernel code too, except for very low-level areas (serial console, pmap, and interrupt handling come to mind) where you can't safely ask the scheduler to do anything for you.
That said, our sleep locks are actually adaptive locks, so on SMP systems they'll spin for a bit before giving up and asking to be descheduled.
They are encouraged in the Linux kernel in places where it is nessesary to lock for a very short time. Using mutexes takes a bit of overhead, so they can't give you very short sleep times; that is when spinlocks have to be used.
In FreeBSD the vast majority of sleep lock acquisitions are uncontended and end up being a single compare-and-exchange -- very fast. Spin locks are slightly more work, since we disable interrupts during them.
Spinlocks in linux are the "last resource locks", usually in kernel code only in situations where you can't have the scheduler kicking in but can have a race condition (in SMP systems usually)
It sounds smart but it occurred to me that that I can only think of two situations where a spinlock needs to be promoted. 1. Too many cores access that tiny portion of the system at the same time or 2) a bug(like using a spinlock where something else should be used and a more old-fashioned bug).
Will 1) really happen often enough to not use simple spin locks?
That said, our sleep locks are actually adaptive locks, so on SMP systems they'll spin for a bit before giving up and asking to be descheduled.