HTML can survive on nothing but div and span. A page built from those two elements will still render. But that is not a reason to use them for everything. Most of the richer HTML vocabulary exists because people kept writing the same thing: <div class="header">, <div class="nav">, <div class="article">, and so on. The tag says nothing; the class carries the meaning.
HTML5 continued the pattern. header, footer, aside, nav, section, and article were common class or id names long before they became elements. It is tempting to imagine that part of the standardization process is simply watching which class and id names keep reappearing and promoting the most common ones into tags. Whether or not that is literally how it works, the direction is clear: replace the frequently repeated <div class="{tagname}"> and <span class="{tagname}"> patterns with elements that already describe their job.
There is a well-known example that gets passed around as a masterpiece of old-school HTML:
<div class="mod">
<div class="hd"></div>
<div class="bd"></div>
</div>
It may not disappear tomorrow, but it represents a style of markup that is already fading.
The reverse approach works too. Start with the most meaningful element available. If no tag fits the content, use div or span and give it a class or id. The point is not to ban generic elements; it is to stop reaching for them by reflex.
Do not treat id as a problem
The same thought experiment applies to id. If HTML had only class and no id, pages could still be built and semantics could still be expressed. You would simply end up with a lot of very specific classes. id exists so that class and id can work together: they let a document combine general meaning with one-off, unique meaning even when no dedicated element exists.
The usual objection is that everything should use class because class selectors share the same specificity, while id has higher specificity and therefore “breaks the balance” of the cascade. That balance is imaginary, and there is no reason to protect it. An element marked with an id is usually special; it makes sense for it to win more often in the cascade. It is fine to reserve class for foundational CSS—the kind of base styles found in OOCSS, or in shared files such as common.css and general.css. But that is different from avoiding id altogether.
There is also a larger point: HTML5 gives us more than id and class for styling. Attribute selectors such as E[attr="..."] let us target elements through other characteristics. With tag names, classes, ids, and data-* attributes, there is no reason to lock every styling decision inside the class attribute.
Name layout by role, not by position
A two-column layout often has a main content area and a supporting column. Instead of class="left" and class="right", prefer names such as main-content and sidebar, or use article and aside directly.
Responsive design makes position a moving target. An element's location on the screen is closer to a variable than a fixed fact. A column called left may end up at the top on a narrow screen; a column called right may become a full-width section at the bottom. When that happens, positional class names turn the markup into a lie and add maintenance cost.
Use presentational names only when there is no meaningful content role to describe: an extra element added for rounded corners in old versions of IE, a clearfix helper, or some other low-level styling hook. Those are the cases where a div with a name about appearance is honest enough.
Keep pure styling out of class names
Avoid classes such as class="f14 red". If a style really has to be applied that directly, an inline style attribute is more straightforward. At least it does not pretend to describe the content.
The web moves fast. That speed can make slower fields look stagnant by comparison. Working here means trying things, paying attention to new techniques, and noticing where the platform is heading. Do not reject new tools by default. Do not let inertia hold you back. Stay curious.