"Just serving HTML" assumes you
have HTML to serve. If you're writing a CMS that consists of manipulating a bunch of /posts/[N] resources that are effectively un-rendered Markdown in the "body" field of JSON documents pushed into a document database/K-V store, though, then you've not got HTML. Coming from the perspective of writing the tools that allow you to
manipulate the content, the simplest, cheapest extra thing you can do is to extend that tool into also being an API for
getting the content. And nothing more. You don't want your flimsy document-management service to
serve your content. You just want it to be spidered/scraped/polled through that API by whatever
does serve your content. Exposing your flimsy hand-rolled CMS to the world, even with a caching reverse-proxy in front, would be a security nightmare.
And, even if you did want your CMS server serving up HTML to the world†, you don't want your CMS to serve up "pages", because deciding what combines to make a "page" is the job of your publishing and editorial staff, not the job of the people writing the content. This is an example of Conway's law: you want one component (the CMS) that your journalists interact with, that talks to another component (whatever themes and renders up the "website") that your line-of-business people work with, and you want them basically decoupled from one-another.
There's no reason, like you say, that the same server can't content-negotiate between the web version of a resource and the API version. I've implemented that sort of design myself, and a few years back, I thought it was the be-all and end-all of sensible web authoring.
These days, though... I've come to think that URLs are hateful beasties, and their embedding of an "origin" for their content (effectively making them {schema, namespace, URN-identifier} tuples) has broken the idea of having "natural" web resources before it ever got off the ground. The CA system and CORS have come together to make "origins" a very important concept that we can't just throw out, either.
What I'm talking about: let's say that the journalists are actually journalists of a subsidiary of the publishing company, recently acquired, kept mostly separate. So the journalists' CMS system is run by the IT department of the subsidiary, and the news website is run by the IT department of the parent company. This means that the CMS probably lives at api.subsidiary.com, and the website is www.parent.com.
Now, there's actually no "idiomatic" way to have the parent website "encapsulate" the subsidiary's API into itself. You can allow www.parent.com to load-balance all the requests, frontload content negotiation, and then proxy some of the API requests over to api.subsidiary.com... but api.subsidiary.com still exists, and now its resources are appearing non-uniquely through two publicly-available URLs. You can further try to hide api.subsidiary.com behind firewall rules so only www.parent.com can talk to it, but, now—disregarding that you've just broken the subsidiary's CMS tooling and that all needs to be recoded to talk to their own API through the parent's website—what if there's more than one parent? What if, instead of a parent company, it's a number of partners re-selling a white-labelled multi-tenant API service through their own websites? api.subsidiary.com still needs to exist, because it's still a public service with an indefinite number of public partners—even though it's denormalizing URL-space by creating a second, redundant namespace that contains the same unique resources.
And all this still applies even if there's no separation of corporations, but just a simple separation of departments. The whole reason "www." was a thing to begin with—rather than whatever's on the domain's apex just setting up a forwarding rule for access on port 80—is that the web server was usually run by a different department than whatever was on the apex domain, and each department wanted the ability to manage their resources separately, and potentially outsource them separately (which still happens these days; "blog." and "status." subdomains will quite often be passed off to a third-party.)
In short: REST is awesome, and content negotiation makes perfect sense... until there's multiple organizational/political entities who need to divide control over what would originally be "your" REST resources. You can try to hide all that complexity after-the-fact, but you're just hiding it; that complexity is fundamental to the current {origin, identifier}-based addressing model used for the web. We would need to switch to something entirely different (like, say, Freenet's SubSpace Keying approach) to enable REST resources to have canonical, unique identities, such that you could really encapsulate multiple REST "representations" served by multiple different third-parties into the same conceptural "resource", and have that "resource" only have one name.
---
† On a complete tangent, HTML is way cooler as a format—and far less of a hassle to generate (no templates!)—when you just use it as a pure flat-chunked unstructured markup language, like so:
<html>hi <em>guys</em></html>
...instead of forcing it to be a container-format for metadata that should rightfully live in the HTTP layer. (Yes, the above is fully valid HTML. Validate it sometime!)
While it does make sense to request, say, the text/html representation of a BlogPost resource directly from the CMS server, what you should get in return is, literally, a direct HTML equivalent to whatever the JSON response you'd be getting is, instead of a "page"—that being an entirely different compound resource that you weren't talking about at all.
That's where people screw up REST—by thinking "send me text/html" means "send me a web page." Pages are a particular kind of "microformat" that the text/html representation is capable of! There are other kinds! Sometimes the unstructured HTML markup of a BlogPost-body might be all you want!
Now, that sounds all well and good as an argument for the sake of e.g. REST client libraries that want to get uncluttered HTML resources to chew on. But web browsers? It'd be crazy to feed unstructured markup directly to a web browser, right? Horribly ugly, for a start, and missing all sorts of important structural elements. It'd look like 1994.
Well, surprisingly, you can gussy it up a fair bit, without touching the Representation of the State itself. One thing people don't tend to realize is that the <link rel> tag is equivalent to sending a "Link" header in HTTP. This means, most importantly, that you can tell the browser what stylesheet it should use for a page as pure HTTP-response metadata, instead of embedding that information in the transferred representation.
With enough clever use of CSS :before/:after styles to insert whatever you like on the page, you can "build" a structure around some REST "State" that was "Represented" during the "Transfer" as completely unstructured markup. That's what you should be seeing as the result of letting a browser do content-negotiation directly with a RESTful API server.
(Now, you can't get any Javascript going that way, but shame on you for wanting to; the thing you're rendering isn't even a representation of a compound resource.)
Anyway, follow this kind of thinking far enough, and you realize that everything the "API CMS" server I just described does is something databases do (at least, the kind with constraints, views, triggers, stored procedures, etc.); and that the "website service" of the parent company is what's more traditionally thought of as a "webapp" server.
Now if you could only get your database to speak HTTP and serve HTML directly... oh, wait: http://guide.couchdb.org/draft/show.html :)