And not speaking about the bloat: take for example sending midi to plugins. First there were the "event" extension (some plugins use it) but it was limited and got changed to the "midi" extension (other plugs use this), but hey the developers started to think communicating via an abstract "midi" protocol from the host to the plugin was not sufficiently generalized so the "atom" extension was born. All this means in the midi handler code i need to convert the events for the plugins in 3 different ways, thus bloating the code and maintainability by the size of 3.
This is completely wrong. The MIDI extension defines a type for a MIDI event, i.e. "this bunch of bytes is in MIDI format". It dates from the time of the original event extension, was used as the MIDI type then, and is still used for the MIDI type with atoms. It is not the same kind of thing as the event and atom extensions at all. The second paragraph of the documentation (http://lv2plug.in/ns/ext/midi/) that apparently doesn't exist explicitly says this.
That said, there are indeed two extensions for sending events to/from plugins, atom and event. Oops. Yes, this is mildly annoying for hosts to implement. Mildly annoying as in, a competent developer can implement support for both in less than 300 lines of C, like http://svn.drobilla....src/lv2_evbuf.h and http://svn.drobilla....rc/lv2_evbuf.c.
If even that's too much work and you don't want to support the old one... then don't.
Instead of abstracting and keeping things simple
... writing a fully featured portable toolkit for plugin GUIs is, obviously, dramatically more complicated than just letting developers expose whatever types of widget they want. The UI extension is extremely simple. While it would certainly be nice if a more unified solution was there, it's not the place of the LV2 project to be ramming toolkits down people's throats. The suil library makes it easy to embed any of the popular choices in (Gtk or Qt, so far) hosts, so it's not really much of a problem anyway.
If you want some dictatorial company to tell you what you're allowed to do, by all means, stick to VST or whatever. Those of us actually working on pushing the envelope of what is possible with plugins quite like the extensibility, thanks. Nobody says you have to support everything.