Thanks for this really interesting and opiniated article. I agree that in a lot of use cases involving map data visualization, for efficiency and simplicity reasons, tiled protocols in general is the way to go. In our products we strongly discourage users to use WMS/WCS if possible and make them use XYZ or TMS. Even for large vector datasets XYZ is really interesting, e.g. MBTiles. However, others protocols might have some benefits that cannot be addressed solely with XYZ.
First, I would say that XYZ is more a convention than a protocol. A protocol defines a standardized set of rules for communicating and formatting data. I others words, how you can access data and how you can manage data content. XYZ partly answers the first question (REST) and does not really answer the second question at all. When you use an XYZ URL you rely on implicit assumptions about the projection, the content of the data, etc. And when you claim that "virtually all clients already support XYZ" it is under these assumptions. Changing the EPSG 3857 projection, the size of the tiles or the RGB format of the most popular layers relying on XYZ in the world will make almost all clients simply "break". Clients relying on WMS would probably be more resilient to this kind of changes.
Indeed, most OGC protocols are designed to support datasets discovery (i.e. catalog) and to enable automated processing of data. As you noticed, this requires metadata (data describing the data), so that people relying on XYZ requires additional protocols like https://github.com/mapbox/tilejson-spec to describe how data can be accessed and what is the content.
Yet, WMS is for instance well-suited for print requests, in a single request you can select an extent, a resolution, a projection and retrieve the result without requiring further processing. Using XYZ would first require to load involved tiles with many requests, then perform a complex post-processing to extract the data from the tiles, under the assumption your data is available in the right projection. WCS is for instance well-suited to manage multi-dimensional scientific data and perform subsetting, which is not possible with XYZ.
In my humble opinion XYZ is as hard (or easy ;-) to setup as others protocols: you need specific tooling to process and serve the data, e.g. GeoServer. Exposing data using the different protocols is often a matter of configuration of these tools. OGC protocols are also often too much verbose and complex but new standards like the OGC API Features/Maps vs legacy WFS/WMS try to improve that.
In conclusion, I would say that for visualisation if you can plan ahead the required projections and format XYZ is really the right choice. But if you need something more flexible from the client perspective and address more use cases beyond visualisation you will probably need some OGC (or custom) protocols in addition. Moreover, XYZ usually requires more pre-processing/storage and it can be tricky to find tooling to address weird use cases (e.g. projection/tiling different from world-wide 3857, file format different than RGB, ...).
