You can still use VST2 plug-ins, granted that SOME of them seem to have trouble working through the bridge.
I, like you, have been forced to use VST2 plugs that I already had bought, but the real reason I am forced to do so, you already pointed out, and that is simply because the plug-in vendors refuse (their right, of course, but yes, refuse) to go VST3. The natural consequence of this is of course that new (or “smaller”, sorry Urs, you know what I mean) vendors will eventually lead the market, like always, and that VST3 plugs will (eventually) be available. 
Some of them must not understand the concept of software development and the need to advance with technology. I mean, many vendors don’t even (or if, just recently) have 64-bit plugs, and this is mostly a compiler factor.
I think that the importance of the protocol abstraction layer between two communicating nodes (e.g. host and plug-in), is often misunderstood or otherwise undervalued.
VST3 introduced this concept, whereas VST2, like most “old” software component standards, is hardwired (hardcoded if you will), and so this will make it easier to expand on in the future (because a new feature can interface “the same way as that other feature”).
A good example of this is the Note Expression introduced in VST3.5. In order for a plug to support this feature, the developer has to add code.
This COULD have been hardwired into VST2, but in order for a plug-in to take advantage of it, the plug would have had to have been re-coded to accomodate the feature.
So both ways (VST2 and VST3) require developers to add code to support a new feature. The point is that VST3 makes that process easier, though initially, the plug-in has to be re-engineered to BE a compliant VST3 plug-in.
I’ve seen posts from a couple of well known plug-in developers that claims (“oh my”) ALL code has to be rewritten from scratch, which is of course absurd. The plug-in itself, already in VST2, has to support the other plug-in formats as well, so the code that make up the plug-in specifics is usually “self contained” anyways, just tapped into from the plug-in framework “wires”.
Meaning, the code that makes the actual effect or synthesizer, is usually coded in such a way that parts of it are already reused in other plug-ins, and apart from the plug-in framework. E.g. FFT routines, general DSP libraries, etc. The framework merely interacts with the plug-in code.
As crohde put it: “When you develop a VST3 plug-in you get the VST2.4 and AU versions automatically. They write one plug-in format and they get 3. That alone is a big improvement for the developers from my point of view.”
As to the OP’s quote from the magazine article. As you can see, they got their information from one side of the “argument”, obviously. (Or maybe the OP only quoted as such.)
Though, I see that people still use the term “start again” and “from scratch” in the argument (from the one side). What a load of horse apples! If a plug-in developer HAD to do that, I would agree with them, that it is a pain. But also, in that same breath, I would suggest some alternate business to make a living from. What you WOULD have to do is much reorganizing the code (can you say copy/paste), change code to accomodate the framework interactive differences, though the plug-in in itself is still the same plug-in, save a few changes here and there. This does not seem like “from scratch” to me!
Mate, Steinberg has not “failed” with VST3. The vendors that cannot see “any reason” (I am sure many, at the time, could not see why a piece of paper should be used to whipe ones behind, when there are leaves available for free) to move to VST3, are the ones failing. Not matter what the reasoning is, Steinberg is not going to abandon something that is getting better every day, for yesterdays that COULD have been.
Note Expression is awesome!
Think, to be able to manipulate each drum note separately from one another in a drum patch!
