CSS only needs additional elements in case you need to apply structures which is not already present in the HTML. To layout something as a grid you need two levels of grouping: what delimits a cell and what delimits a row. Free-from dt/dd sequences does not contain this information, since there may be multiple dt per dd and vice versa. If dt/dd could only appear in pairs (like in your example) you could say there is an implicit structure, but this is not necessarily the case.

> you need two levels of grouping

Not necessarily.

I can define

   form { flow:row(label, input select textarea); }

to have typical form's two columns layout with all <label>s go to first column and input, select and textarea go to second. All non-matching elements are replaced as if they span full rows (like <caption> in tables).

People at trying to simulate these things by using float and clear. Ugly, non-reliable, etc.

It's already a good idea to add elements where logical, even when unnecessary, to aid styling, scripts, coder comprehension, and sometimes automated comprehension, and to reduce likelihood it must be edited later. One could argue that rows always form logical units - certainly in the above example - and thus should always be wrapped. WHATWG does permit wrapping dt-dd groups in divs.

That "good idea" has a name "tag soup".

But even you can add some non-semantic DOM elements...

What if you have

    <ol>
      <li>first</li>
      <li>second</li>
      <li>third</li>
    </ol>

And you want to replace them in two,three,etc. aligned columns (depending on view size), like these:

   @media handheld {
      ul { flow:vertical; }
   } 

   @media ... {
      ul { flow:row(li,li); } // two columns
   } 

   @media ... {
      ul { flow:row(li,li,li); } // three columns
   }

Not that I diagree with your premise, but in this particular example the WHATWG HTML Living Standard now allows containing divs around dt/dd pairings[1] and browers support this fine.

[1] https://html.spec.whatwg.org/multipage/semantics.html#the-dl...

That requires change of existing markup and somehow its semantic changes too, right?

Yet this is not "resolution friendly".

Semantics is defined by the specification, so in this case no. But yes, a change of the markup.

What if space allows and I will want to have four columns table:

    dl { flow: row(dt,dd,dt,dd); } 

Changing markup structure is not a good idea if to consider that the same markup shall be used on different medias.