1) JACK was not conceived as a plugin system. It is there to connect processes. The cost of context switches is too great for this design to scale to a level that can replace an in-process plugin API.
2) because of this, JACK will rarely be handling audio data flow that is "complex" - that kind of thing happens inside of applications, and rarely between them.
3) JACK2 (aka jack 1.9.X or jackdmp) has support for parallel data flows
4) It is not true to say that user space cannot be hard real time in a practical sense. If you approach the absolute definition of hard real time, then almost nothing on Linux, even with an RT-patched kernel, is hard real time. In the sense of providing sufficient timing guarantees to meet the hardware limits of current (and imagined) audio interfaces, the RT-patched kernel makes it possble for user-space code to be sufficiently hard-RT that the difference between these two definitions doesn't matter.
5) Linux is already used by "hardcore professionals". There are at least 3 manufacturers of large scale mixing consoles in which the DSP signal flow is being handled by Linux on more or less off the shelf components. Their users, of course, don't see Linux at all.