Yep, there's pretty much no reason not to use semantic HTML at this point. The only thing that could have possibly ever stopped you using it in the past was IE's awkward browser support for nav/aside/article/whatever in IE8 or so, but come on. It's 2019 now, and chances are, your web app probably wouldn't work in such an outdated browser anyway.
Semantic HTML is more than a few easy steps to clearer document structure. For example, to ensure that screenreaders process your page correctly, you have to wrap every single foreign-language name or phrase sprinkled in English text in <span lang=""> tags. It is evident that the majority of web designers and content writers can't be bothered to do that.
Of course, whilst there are obvious cases where inline tags specifying a language are helpful for screenreaders ("Martin" is pronounced very differently if it's a French name, in a way which wouldn't be obviously inferred from context), there's also a reasonable argument the makers of language parsing tools are better placed than content writers or blog comment authors to determine which language dictionary it should use to read cafe, malbec, Cologne, Mohammed, Zeus, Patel, chutzpah, faux pas, schadenfreude, ain't or ad infinitum from (unless otherwise specified)
This is it. Not only were web developers much more "bothered" with putting actual effort into trying to produce a considered product in the past, they did so without the tooling we take for granted today.
Half the projects I've worked on recently use contexualised i18n wrappers to process and output strings, or an equivalent custom generic React component, or similar. How simple would it be to add `lang=""` support to such a workflow, compared to what would have been involved in doing this 10 years ago (I'm aware this might seem exaggeration as 10+ years ago we still had similar stuff with gettext, et al—still used today by even Wordpress—but I'm more talking about recent changes to tooling-oriented frontend web development, which should in theory have made this type of stuff a lot easier).
As an attempt to sway you, consider that I'm in no way suggesting that the past was good, rather just that the present is worse.
Also, a caveat is that I'm not saying it was a better/nicer/more fulfilling experience doing frontend development in the past (e.g. IE <7), but rather that developers put in more effort, were more considerate, and generally achieved what little they managed to achieve within (what would today be considered) severely restricted environments, with far fewer resources / tools at their disposal.
Whether the output of that work was a better product is debatable, but I don't think it's untrue that devs did more with less (and when I say "more", I don't mean mean bloat).
A lot have happened to HTML since I started with web development in the 90's, but I'm still waiting for the semantic web to catch on ... One problem is the rule of least resistance, people will usually do as little markup as possible. Adding schema itemprop etc is a lot of work for very little gain. The only effect is that it's now easier for Google to scrape your web page to show the data in the search result, instead of sending the user to your site. You offer free lunch, and your biggest competitor takes it all, then sell it for profit. For this reason, sites like Facebook and Linkedin make a lot of effort to make it hard or impossible to scrape data. There are also a lot of other sites that keep hugging their data, walling it off from the rest of the word. This is why the sematic web have a very hard time, even though it's such an great idea.
Quite a few SEOs would say it's better to have your page shown in the infobox, even if people can get the answer there, since it pushes your competitors down the page and out of view for that query. If you're both first and have that giant sidebar/top block in your favour, you're a lot more likely to get clicked than if not.
there's a difference between the semantic web and semantic HTML though - semantic HTML is particularly important for giving accessibility hints for example.
There's no excuse for div soup any more.