I have to agree that the lack of proper governance is a big problem in an SOA.  I have been pushing for the purchase of WSRR for several years now in my current organization because of the rouge nature of our services.  Basically its every service for itself.  I see textbook examples of why we need SOA governance regularily.  However, even if we could get the funding for WSRR, I believe greater funding is needed for proper ongoing governance. 

In my organization our application teams operate in their own silos, and are resistant to any form of central governance.  This means leadership must break the mold and enforce application teams to comply with a centralized governance for SOA to be successful.  We could have all the tools like WSRR in place, but without executive support and application compliance, we would not be successful.

For example, an application team hosts a service, they upgrade their service, move it onto a different server, do not use a DNS name for the service endpoint, do not supply a WSDL to consumers, and they take the old service down.  The application team is aware that others use the service, and they are sure to update the endpoints for their own application usage, but dont tell any other consumers of the application.  When support calls come in, they dont even realize this is their problem and refer the issues to the service consumers who cant connect to their service.

Now, put all of the tools in place such as WSRR, ESB (or WMB in my case), governance policies, and a governance team.  What if the application team doesnt do endpoint lookups in the registry, and instead hardcodes its endpoints wherever used?  They are able to skip over the governance.  They dont need the new version of the service and endpoint approved in WSRR, they have implemented the new version of the service (for their own purposes anyways), sidestepping all governance.  Without enforcement that they resolve their enpoint through a registry lookup, and thus needing to go through SOA governance and approval to make the new version of the service discoverable, the SOA is undermined.

Another issue is SOA knowledge and training.  SOA is a contemporary IT buzzword, much like "cloud" that alot of people like to throw around to make it sound like they are on the up-and-up, but they really dont know what it means.  Like you say, some think it is limited to WebServices. Some think it applies only to applications and not EAI, and vice versa.  Some think a WebService by itself is SOA.  I am seeing more and more universities encorporating SOA in their cirriculum after a good dose of Object Orientated design, but organizations need to be sure they are providing training to those who havent had any SOA exposure, or even any formal IT training.  You cant get by with what you read in Information Week or some other publication/advertisement.