Load/acquire and store/release are sufficient pretty much when you're implementing a mutex-style operations, so you have a lock on a single value guarding vanilla memory operations that are unused outside of the mutexes. In pretty much any other scenario, (including, notably, most lock-free algorithms), it's best to start with sequential consistency and don't try to relax the memory unless you can prove correctness.
The actual bug in question used relaxed memory ordering, and the fix was to use acquire/release. Relaxed memory ordering really should be reserved for scenarios where you need atomicity but absolutely no synchronization (statistics counters are the only case that readily comes to mind).
Note that C++11 std::mutex and C11 mtx_t require a single total order of operations on the mutex, which means acquire plus release pairs equivalent on lock/unlock. That is actually weaker than acq rel write.
POSIX requires memory barrier in addition to that on the pthread pair, making it get more different, and both major C++ library implementations defer to pthreads.
Usually it is not. Acq rel only is useful when you can prove ordering of everything else can be nonsequential but still need internal (in-function) ordering guarantees. Generally you really have to run a miniature proof or exhaustive ordering analysis to be sure.
It is useful when implementing nonserialized queues. (especially if you keep a Lamport timestamp or equivalent yourself for other reasons)
Release write/relaxed read is more useful, typically for work/cancel/finish flags that are spun on similarly to condition variables.
My understanding is that acq_rel is sufficient for many use-cases, as opposed to seq_cst.