1. the classic: seo
When the internet finally reached the big masses, getting your site noticed became increasingly difficult on an ever expanding web. Around the same time semantics came into play after years of abusing html for whatever designers asked us to make. Seemingly unrelated at first, those two concepts would find each other in a rather unlikely marriage.
Semantics made things a lot more difficult though. Writing html became a skill that actually required knowledge of the language. Then again, it benefited css, accessibility and machines alike, but sadly those three arguments were hardly convincing. Especially when implementing these new html structures lead to back-end development issues (which it always did, as all of sudden the default cms code wasn't good enough any more).
But then seo came along and thanks to Google seo became the perfect wave for us html guys to latch onto. Correct use of headings, paragraphs and tables ... they were all taken into account when determining the position of a site in the search results. This opened up a path that forced people to take notice of our html. It was a lever we used to force our own html in a project so that not just css and accessibility would benefit, but that we were finally able to deliver some properly structured html code.
2. updating the classic: responsive
Nowadays cmses churn out pretty acceptable html, at least from an seo perspective. Most of them are still pretty html5-agnostic, but the seo-argument has definitely lost some of its weight. That doesn't mean we just have to comply with the default html of popular cms systems though. Our new lever: responsive web design.
Position:absolute; and box:flex; are our life savers here. They require specific structures that are often lacking in default cms code, meaning custom html code is actually required to make everything work in a way that doesn't break a page whenever it appears in a different viewport.
3. the new kid on the block: performance
Performance is our lever when we want to scale down the functional complexities. Recently a lot of tools have appeared to help us determine the exact impact of certain techniques on the overall performance of a web page, which is a great help when trying to block those exact functional demands from being implemented.
a word of warning
Just remember though: while the three arguments above are all valid, they are not holy. If you go around yelling at everyone they can't have X or Y because of performance and they need to implement Z because of responsive needs without solid arguments to back up your claims, you're not going to be working on the project for very long.
Use the above arguments in valid cases, but when such a case present itself you can try to use it as a lever, sneaking in some extra bits and pieces that will improve the overall quality of the front-end code. Trust me, everyone else is doing this already (designers, information architects, back-end developers), so don't feel too bad about it. Just don't be too obvious when you're doing it.