At the urging of @wonderchook I did an Ignite talk at WhereCampDC titled: WMS is Dead
I feel that I've flogged this issue enough but nothing like putting in finishing nails in the coffin to tidy it up.
Architecture and Scaling
WMS was designed in the late 1990's, when we really didn't understand how the web worked at scale. I think that the dominant mental model of web services at that time was RPC and it's evident in the architecture of OGC W*S. The architecture was designed to mimic GIS systems, so WMS requests are standardized RPC calls to an abstract model of a GIS. Where WMS went wrong was that it ignored existing Web standards and that the Web's architecture and infrastructure was optimized for delivering documents via links. Ignoring URIs to retrieve standard well known mime types such as pngs contributes to it's clunky interface. Retrieving tiles via URIs is a Web native operation; whilst sending long requests to create a single document is not. That being said, I believe that layering a REST interface over WMS is a futile exercise in trying to hang with the cool kids. As Bruce Sterling often says, "Good luck with that."1
In WMS, you make make maps with SLD. I can't say enough that SLD is a bad idea. XML is for data, it should not be perverted in a single configuration, query, and pseudo programming language.
Projections have been cited as one reason WMS is superior to tile based mapping. My response is that Web mapping is a different medium from traditional cartography. In traditional cartography, the map maker has only the X and Y dimensions to convey information; which makes projections one of the most important tools for the cartographer. In web mapping, we have n dimensions to present information from info bubbles to interactive tools. Projections are still important for operations that require measurement, but that occurs on the backend and is less important for presentation.
WMS fails at interoperability because it is implemented at the application level. Chaining together a bunch of applications through a series of client requests does not result in a performant web application. In addition, WMS stateless (request/response) operations bypass web native optimizations such as HTTP caching; which has led to software such a MapProxy to overcome this shortcoming. Again this is a bandaid solution to a deeper architectural problem.
Interoperability should take into consideration how the Web is designed rather than providing an overlay that implements loosely-coupled client-server like architecture over the Internet. This means that interoperability should occur at a much lower level than application to application communications, such as data and document types.
I think that the prevalence of tile servers proves the point that URIs plus well known mime types trumps Web RPC. Data is out of the scope of WMS since it is primarily designed as a presentation interface (with lots of kruft), but I think it is important to the future of Web mapping as well as interoperability.
1In all fairness, WMS was designed to retrieve a map dynamically based on a user's request. The use case was not, "I want a fast background map with data sprinkles"; which is the real world use case.