Beyond the communication issues I think there were several reasons why rtkit didn't get a particularly favourable response from the LAD community.
Firstly, the rtkit solution requires that any application wishing to use rtkit becomes dependent on dbus. For many authors (particularly of software aimed more at professional use) this is not regarded as a good thing for a number of reasons (technical and otherwise).
Second, as was mentioned in the article, the RLIMIT_RTTIME limit was presented as "the answer" in the 2.6.12 days. Many of the shortcomings of RLIMIT_RTTIME were mentioned at the time RLIMIT_RTTIME came into existance. The stated solution to these was that userspace support of RLIMIT_RTTIME would take care of them. The problem is that the promised userspace support applications/daemons were never written. It is argued that instead of introducing yet another mechanism we should instead be concentrating on making RLIMIT_RTTIME work as it was intended. To take one example, one of the distributor's concerns about RLIMIT_RTTIME is that it grants RT scheduling functionality to all processes started by a given user. Technically though such a broad grant of the RT privilege isn't necessary as demonstrated by other userspace tools such as set_rlimits(*). The reason that it *is* an issue is because the integrated tools to make it happen don't exist.
Third, some developers have claimed (on the LAD mailing list) that in practice rtkit does not in fact protect the system against very much at all. I haven't evaluated the arguments in details but to my knowledge their concerns have not yet been addressed.
Forthly, many (but not all) developers on the LAD list are associated with software which is aimed more at the professional user than the typical "desktop" user. They see rtkit as something originating from the desktop scene which is being forced onto professional users without any thought as to what effect this might have on the pro users.
Finally, rtkit is Linux-specific while many audio developers support their software on a multitude of platforms and operating systems (both free and otherwise). Using rtkit introduces yet another point of difference that they have to manage across the supported systems - an overhead many, it seems, are unwilling to accept.
As a result of these and other issues aired on the LAD mailing list, many audio developers simply don't see rtkit as a viable solution to the audio problem from their point of view. As a result of the clearly polarised reception of rtkit I'm not entirely sure that "the audio community will eventually move to make use of it". My concern is that it will in fact further fragment the community - that we'll see developers of desktop applications embracing it while those of pro applications will not. This will hardly lead to an improved Linux audio experience all-round.
I certainly have no arguments with the motivating reasons behind the development of rtkit - setting up audio under Linux is problematic on a number of fronts and needs to be improved. While I can understand Lennart's frustrations and the reasons behind rtkit's structure I can't help but wonder whether discussing the basic problem with a *small* group of significant stakeholders representing both desktop and pro audio users might have resulted in a system which was acceptable to all.