Problem 1: White-spaces

I believe that this hasn’t come up in general. Although, one good reason that this hasn’t and probably shouldn’t happen is because white-spaces in CSS classes define multiple classes for the element, while in HTML they define attributes.

Explain (or ask a browser to parse) the following code:

<pet family style=" ... ">
  <img src="my-pets-family.jpg"/>
</pet family>

Is family the definition of a second class or an attribute to the HTML element? As you probably see from this site’s parser, it thinks it’s an attribute.

So, if I want <div class="pet family">, there is no way to actually define two classes, which is one of the two main reasons that I would use a class instead of an id, anyway.

Problem 2: Forward compatibility!

Using <div>s at the moment, forces us (at least some of us) to properly indent and comment around our code, which is a good practice for all programming languages.

Instead, turning HTML blocks into variables would cause big confusion to new programmers as to what is and what isn’t doing something specific in HTML.

Also, it will cause the funny side-effect that you should start comparing your old code against new HTML5 tags, just to make sure that they didn’t come up with the same name you did for your div’s classes…

Same problem applies to variables using reserved words in some languages. PHP solved it with a dollar-sign, so a similar approach in HTML would result into something not much better than the current usage of <div class="something">.

We use <div> instead of whatever tickles your fancy because it makes processing and rendering by the browser easier to accomplish.

As a counter-example, XML allows the creation of any tag-name that you want. The ability to create arbitrary tag-names comes with a processing cost. XML parsers have to build a dictionary of the tags used within a document as part of / while it is parsing the document.

By using <div> browsers know that there is a container there and that it can ignore the container or pass it along to some other tool in the chain that may do something with the container.

You are suggesting allowing web authors to add arbitrary element names to HTML for private (non-standardized) purposes. This has a big problem: It will make it dangerous to add new elements to the HTML standard, because various authors might already be using the the same element name for private purposes – thereby retroactively changing the semantics of the page. People don’t get happy when new versions of browsers break existing web pages, so this is a no-go.

The same problem is with using arbitrary attribute names for private purposes. This is why HTML5 mandates the prefix “data-” for private use attributes, so they wont collide with new attributes in the standard.

Div and span are defined as semantically neutral elements, which means you can use them for private purposes without fear that the semantics will change in future browsers. Sure, it requires a few more characters to add a class name, but forward compatibility makes it worth it.

Your own example displays one property why divs are not that ridiculous.

<div class="hero-img">
  <img src="https://whatever.com/this.jpg">
</div>

You have, correctly, not closed the img tag. Some tags, such as img, br, hr, and others do not have any content, and are therefore not to be closed. The parser knows this.

The div tag, on the other hand, is supposed to be closed, as it contains content.
If you just whipped up you own tag, the parser would have no idea if it should expect the tag to be closed or not.

The reason why some elements are to be closed and others are not comes from the SGML heritage, which this blog post describes nicely:
http://www.colorglare.com/2014/02/03/to-close-or-not-to-close.html

It is a matter of definedness. If using XHTML, which is pure XML, hence fully defined, then you could use your own namespace, here for instance via a prefix q::

<q:hero-img>
    <img src="https://whatever.com/this.jpg">
</q:hero-img>

If you would use XML to convert to (X)HTML you would be entirely free to generate from your free-tag “HTML” real HTML with <div class="hero-img">.

In some tag a namespace attribute with your own (dummy) URL:

xmlns:q="http://..."

One of the key elements of HTML is actualy having predefined tag-elements. That’s why.

The div class= is a way to get around this “limitation”.

And that’s why you don’t see those “implied” constructions.

The purpose of a div element is structure alone. It lets you group elements together under one common element. It has nothing to do with white space, speed, rendering, semantics or anything else. It helps you with CSS in terms of styling and javascript in terms of selectors. If you change it to any other element then you change the purpose.

To create your own named element, as you show, has a problem in that search engines and other tools would not know what your elements meaning had. What is a “hero-img” and how is it different from my “hero-image” and how should my API handle that when I visit your page? How should a browser handle that element? Is it block level or inline? Too many questions.

Generally, div tags are useful for applying division or section in a web page.
You can use a div tag as a container in which other elements can be applied. It will also help in applying CSS and some scripts on a particular element.