Imagine the case of a generic news article: the body of the post can contain text, photos, pull quotes, videos, a slideshow, audio content, etc. The CMS needs to enable users to add all of that content and expose via the API to multiple clients (web, mobile, feeds, etc).

I always thought that fields are generally poor for that - html is pretty good and has ways to structure all those things, and they can be extracted and styled for different clients.

You can still do that with most field oriented CMS packages. The field interface is generally admin facing only.

The user facing html templates have variables that map back to those fields. So, all the expression of HTML, but with the actual data in fields.

Handy for things like addresses. You can render a map or just text, or both. The fact that it's structured data would allow for proximity searching. Where each "post" is say, a restaurant location.

Similar for things like tags, so that you have built in taxonomy. Separate spaces for tags too, so that you could have a topic taxonomy as well as a completely separate taxonomy that doesn't pollute that space. Like an author taxonomy or similar.

It generally limits you though, eg one video per article etc.

Depends on the CMS. Many have repeating fields that you reference in an array style notation from templates, or via loops.

Others allow content relationships, where videos are their own object, set not to be published alone, but embeddable into, say posts.

HTML as a data entry format is error prone, and HTML as a cross-platform data source requires a lot of tooling and unreliability compared with a properly-structured field-driven JSON API

If you have the luxury of convincing your users to learn markdown instead of structured fields you'll have a far simpler and extendable solution.

Obviously rarely the case, but worth having the conversation.

Any decent CMS would add tooling there (yes, they don't they just treat the HTML is WYSIWYG, but that is where the tooling should be)