Well, from being a long time Linux user... and without having bothered downloading the VST3 (probably won't do it before I have a host that supports it, and I have no plans of becoming Steinberg customer so..)
In the past, there was a dark time when gcc updates tended to cause trouble with C++ libraries. I think it was still the case with early 3.0 series. Mostly the cause was incompatible name mangling though. I don't remember seeing a compiler update breaking anything after they standardized that... maybe something esoteric like multiple inheritance could have broke it, but who's stupid enough to use that kind of stuff on a library API is beyond me. Anyway, considering that nowadays (read in the past ten years or so) C++ has slowly gained more ground on Linux desktops, I guess there is quite a bit of pressure to keep the whole ABI stable.
In the open source world, stuff usually happens as soon as there's enough people that need something and are willing to do some work for it. Unfortunately that also means that the gcc ABI will change, if there is ever new important functionality added to C++ that can't be sensibly supported on top of the old ABI. It might be standard now, but until it's at least 10 years old, I'm not going to bet money that there ain't gonna be any revisions.
Anyway, I still dislike C++ APIs 'cos C++ is a language that you just can't say you know well before you've used it in real life for 10+ years. And the really funny part is that some code of mine that was perfectly valid C++ 10 years ago, doesn't even compile with modern C++ compilers, 'cos the damn language has changed in source incompatible ways (ok, not big changes, but it's still annoying to have to tweak sources when you expect a simple recompile).
For a library, the problems are 10 fold, because C++ is also a language where single bad decision can dramatically limit what kind of things you can realistically do (often because somebody f**ked up the resource ownership logic, but there are other ways as well). The more annoying part though, is that wrapping a C++ API is invariably more work than wrapping a C API, 'cos C APIs don't try to force a certain class model down your throat. One good thing about the VST2 C++ API was that it was essentially just a sensibly thin wrapper around the C dispatching mechanism.
Oh, from what I've read here what has been said about said C++ API of VST3 feel sorry for anyone writing plugins in a language that can't talk the platform-specific C++ ABIs natively. That'll mean that someone might have to write a C++ to C wrapper just to be able to wrap the C version for their language of choice then. After all, it is rather well known that if you want a language agnostic library API, then on most platforms C should be the choice for anyone that has a clue. So I guess language agnostic API was not desired.
Btw, is the VST3 API exception safe?