As someone who spent nearly a year with one support case dealing with missing records from dropped messages, the problem Service Broker is much bigger than education.
From a support perspective, there's only a few people in MS support who understand Service Broker--Do you really want to build critical business functionality which has little support?
Related to support issue, sometimes there's wisdom in following the mainstream. Since most customers do not use Service Broker--This inevitably leads to more potential bugs you're more likely to encounter because less people are using a particular feature or configuration. I've learned this lesson in my career early with SQL Server running Itanium platform, there were unique issues with this platform which were not encountered on x64 or x86. You don't want to be the 1%, 5% or for that matter 10% of customers running a particular configuration.
Microsoft should have done more to build core features on Service Broker i.e. eat their dog food. If you look at Oracle Streams (or successor GoldenGate for Oracle), both are based on Advanced Queuing which is basically Oracle's equivalent to Service Broker. There's a big potential here with SQL Server replication which is hopelessly stuck in an architecture right out of the 1990's.
In looking at any technology for providing business functionality we need to ask three questions: How well is the technology supported? What percentage of customers are using the technology? Is the technology used by the vendor to provide other products or features?
In my case, we decided to rip out Service Broker and replace with middle tier functionality.