Why? Because it makes the document readable... for machines.
You may think about browsers, but if your HTML is a mess, devices that translate content into Braille or read it as audio, won't be able to make sense of it.
That might not sound like a problem, but this might very well cause legal issues in some business cases (e.g. people with an impairment can't access a website of a public administration? That might be a civil rights violation in some countries).
Another reason is because it makes it easier to extract data and information from HTML documents: search engines and search spiders. If your HTML is a mess, you're going to take a SEO hit.
That's just two concrete concerns that come to my mind right now.
HTML and CSS today are mostly used for presentational & interactive purposes: push UI components in there right place, with the desired shapes, colours, fonts, animations and so on, in order to build complex interactive applications.
But HTML wasn't originally conceived for that purpose. The word "markup" says all you need to know. The entire purpose of a HTML tag was simply to describe the structure of a text document: this bit here is the header, that bit is a paragraph, the next bit contains an image, and here are a few meta tags with extra information about the document you're reading.
However, as markets drove demand for more and more interactivity - applications in browsers rather then just static documents - browser technologies including HTML evolved beyond the original scope of "marking up text documents". That original design foundation is still there: marking the content structure of a document through HTML tags, though.
The problem is that developers want to cater to demands to build these nice fancy UI experiences that need to be rendered perfectly on various devices. And so, the original intent of HTML goes right out of the window. What's left is an unreadable mess of spaghetti HTML, mangled DOM's with non-sensical auto-generated CSS classes to which one needs compilers and transpilers and entire toolchains as you write your CSS in an entirely abstracted fashion.
When you're building a complex interactive application for the browser. That's just the current state of affairs one will have to accept. Presently, you're still, in essence, using tools that originally never were designed for that purpose.
However, if you're just going to build a simple blog or a site with static content, it pays dividends to think about the structure of your content, consider the semantics of your HTML and the CSS classes you're going to use. Using pure CSS, you could then easily write lean, performant and understandable stylesheets that don't need to be processed by complex toolchains. And you certainly wouldn't need complex frameworks to build a website.
Of course, YMMV, and so there's definitely a market for Tailwind and their ilk. I do think that developers should learn about "golden hammer" syndrome early in their career: while frameworks make your life as a developer easier, they aren't the best choice in all use cases.
From the perspective of a "body shopping" business, it makes sense to standardize the process as much as possible and fall back to a few well known tools and practices with repeatable - and therefore measurable - outcomes. In the same vain, the big trade off here is providing any form sanity/clarity when someone hits the "browse source" button in there browser.