You can use the C wrappers in C++ code, of course, but it's often not very convenient. For example you normally have to call destructors of the objects created by the library with explicit calls to some C functions from the C wrappers API. By adding another layer of the C++ wrappers over the C wrappers you retain the ABI stability without the awkwardness of C style code in your C++ client code.
I find this is the first thing a lot of C++ devs do if the wrappers don't exist. It is actually kind of important in C++ if your app uses exceptions and you want to have exception (somewhat-)safe code. Using the C API directly would require a lot of boilerplate to ensure all allocated things are cleaned up if an exception is thrown.
I don't really understand why you can't expose a stable ABI right from the first C++ layer. It shouldn't be any harder than making such ABI in the third layer, and will avoid many extra function calls which don't come for free.
It's enough to add a member to a class to break its ABI compatibility. It's possible to expose a stable C++ API but that normally requires extra classes implementing the PIMPL idiom, so basically the 3rd, C++ layer described in the article. PIMPL doesn't require the C API (2nd layer), of course, but if you need the C API anyway, for calling your lib from scripting languages, for example, then the 3 layers make sense. Lots of tedious work, but that's C++...
As far as the number of layers is concerned it's the same. The advantage of writing the C++ stable API on top of C API is that both C and (stable) C++ API have the same functionality/semantics - if you write those two separately on top of the primary C++ API they can easily diverge.
