Well, It Depends™. The spec (more or less) doesn’t break in general, so whatever worked then will work now, especially from a plugin point of view. Like I said, there’s a lot of work going on to make it easier, but that is currently mostly focused on hosts. There is now Pugl, for example, which is slated to become part of LV2Kit and deal with the lowest layer of the X11 (or MacOS, or Windows) UI problem in a more “official”, centralized, well-tested, etc way. Ultimately, though, that’s just a support library and you’re free to make a UI however (which is a good and necessary thing here in reality). That’s just how things go: the UI situation, for example, has been a mess for ages (mostly starting out with the massively problematic “just use Gtk or whatever”), and it’s slowly becoming less so by consolidating all the lessons people have learned into a single place so bug fixes and features and whatnot can accumulate for everyone to take advantage of. This is a tedious and slow organic process, but that’s also why LV2 exists unlike so many other pipe dreams. I personally get frustrated at the mess because I’m somewhat neurotic about software quality, but that doesn’t mean I don’t think plugins should implement LV2. It’s important to take a step back sometimes and realize that what we have here is a whole lot better than nothing (the proven alternative in reality). Maybe parameters or whatever kind of suck thus far. Whatever, we can make ones that suck less then. Onwards and upwards. For all of its faults, LV2 evolves a whole lot better than VST does.
if there was an official LV2 SDK, with examples, documentation, resources, license, etc then I would be more inclined to consider it as a possibility
Well, that’s good to hear, and why I’m making it (aside from the “license” thing anyway, everything is and has more or less always been ISC). It’s called “lv2kit” and there has been a lot of progress there… but few people seem to really recognize how much actual effort all of that stuff takes. There is indeed a chicken & egg problem with some of the tech itself, but just the documentation part alone is probably the better part of a year of work, for example (this is essentially like writing an entire full-size textbook, and then some). It’s easy to wish for everything to be done and perfect before investing at all, but I (or anyone else contributing to LV2 itself) have to actually decide on the implicit “or” behind all those mentioned things. Which one would you do? These are not easy choices to make, especially when you have to weigh the desires of so many different kinds of developers in the process (some of which are relatively silent and don’t participate in discussions like this at all). Many of them are even at odds with each other. For example, the host support chicken & egg problem is a big one, and nobody will really care much regardless until at least some of the big commercial DAWs support it. Yet many in the current niche community are at best not interested - more often actively hostile to - much of the stuff that would need to happen for that (easy vendoring of all the support libs, better documentation for “outsiders”, C++, IDEs, and so on, for example). Do you do that, then? Try to make things shiny for hypothetical new adopters instead of improve functionality and whatnot for existing ones? Meanwhile everything else rots…
Sometimes people even wish for things they definitely do not actually want. The official LV2 GUI toolkit is probably the best example of that. They may think they want some perfect fantasy version of such a thing, but very definitely do not want the reality of one enforced LV2 toolkit getting in their way, particularly when there is no real reason to ram such a thing down everyone’s throats.
Documentation? I (or whoever) could spend a whole year writing the best software documentation the world has ever seen, for example, but how smart of a decision would that be? How much of a blocker is that for people really?
All of which to say: software in general is hard, but software that dictates the interactions between hundreds of different players who all need to get along and can easily blame that software for everything is a whole lot harder than that. Concretely, these sort of decisions are why I’m not directly working on Ardour right now at all. How long does that make sense to do? 6 months? A year? 2 years? 5? 10? Forever?
Anyway, to more directly answer your question, I think both myself and Paul are right at the same time. Sure, the basic idea is mostly done, and people are free to build on LV2 to do more or less whatever they want to do with plugins. It could be better, certainly, but mostly in a superficial sense.
In general, my recommendation for adoption is the same as it’s always been: if you’re willing to collaborate with other hosts and plugins to get things done that aren’t thoroughly established yet, hop on board. Nothing’s perfect - least of all VST - but people seem to get on just fine. If not, well, don’t.
Alternatively, not to put too find a point on it, but there is of course a third option. I try to support other free and open projects because they pay back in kind (e.g. with code). Commercial proprietary developers who aren’t willing to do so may pay in cash instead. It’s pretty easy to make things happen across the whole ecosystem and be standardized pretty quickly if you want… it’s just not free 
- the core is not that different from any other plug-in API - LV2 doesn’t really (need to) offer anything new in that respect, what is often a source of confusion is understanding what extensions are likely to be supported in which hosts, which ones are no longer supported etc and which ones should or could be used by a plug-in for maximum platform, OS (and host) agnostic support.