Let me start by saying I am the most vocal person about semantic HTML at my company, but it really depends on your purpose, and I'm not sure you are realizing you are taking a hard line. Also, I would have preferred you used the 90% of your words to give better examples of how to do things better than overstating how OOCSS and BEM are wrong. Well developed solutions are always better than just explaining what's wrong unless there is no solution and the existing proposals are wholly unsatisfactory.

Take a step back and realize that there is at least one more way of doing this. Why not have the presentation be the specification, and we can just build the html to conform to the that specification instead (via the use of helpers and all other commonly accepted forms of duplication reduction). Your post basically declares this Doing It Wrong™, but I imagine that's just because you'd rather see better looking html than you would see better looking css.

You have the semantic issues well thought out, however you are flat out declaring data semantics are more important than presentation semantics. For most projects, the HTML is only used in a browser, and isn't the source of truth for the application, i.e. it is inherently coupled with the presentation. They might as well be one and the same because this is it's only purpose in the world. Leading from that, the only issue is maintainability, and here is where your ideas aren't fully developed.

As will all separation of concerns, your solution (the one about breaking news) also adds a layer of misdirection. Sure I don't have to change the html to change the presentation, but now I have figure out where that part of the presentation is modified. My CTO and designer (2 people I have a lot of respect for) were the people who eventually changed my mind on this. They said, "I don't know why this button is blue, but it's supposed to be green". Well it turns out it's blue because it has the class blue on it. Instead of trying to figure out what selector was causing this button to be blue, all I had to do was remove the blue class and add the green class. It took 15 seconds. It took probably 3 or 4 weeks for me to relent on this before I accepted, but it is much easier for everyone (think of the new hires as you pointed out!) if they don't have to know tons of info about the domain, but just look for the offending element and make a simple change in place rather than have to unravel the css toolkit to find where my button was made blue instead of green. Additionally, they know this change is only affecting this one element they were told to change. On our team, that is better maintainability because that is how real changes are specified. In your case, by the time this spec makes it's way to the developer, it needs to have traveled through people who know that part of the web page is a breaking news container and translated from whatever the original complaint was or the developer will likely have another problem to figure out before he can even begin changing what will likely end up being a single css rule.

Loose coupling is simply about defining avenues of change, and it only improves maintainability when it enables making changes easier. This has been extrapolated to mean "does this have to change or not", which is over thinking it a bit. In my example, I made a typical update by changing exactly one thing in exactly one place, without having to traverse any levels of misdirection. Just figuring out how to make one thing not have to change doesn't make it more maintainable.

When we're talking about web pages, it's also important to realize that we're typically not changing just the presentation of static data; we're adding and removing features to figure out what makes this page more useful. The HTML is typically going to change anyway when we're modifying the page, which again leans in favor of a common set of CSS selectors to build against (in terms of avenues of change).

As I said, I'm probably the most outspoken person at my office when it comes to semantic HTML, but it's only when I'm describing actual data, i.e. the parts you read. These parts tend to change very little and can be generated and stored in their already rendered state. The parts that do change more often gain a lot from the benefits of OOCSS and BEM techniques.