Let me phrase the issue in this way:
According to the current specification, we have
- ATX heading syntax and
- setext heading syntax
as two alternative input syntax variations to specify a heading (of level 1 or 2). Given that these options confer no difference in meaning whatsoever, and produce the exact same result, I’d say that having a “rewrite rule” connecting them would be “desirable”.
Consider a string {string}, and on the one hand
#⎵{string}⎵#
##⎵{string}⎵##
compared to
{string}
========
{string}
--------
It would be IMO “desirable” to impose as little as possible side-conditions on the content or “form” of {string} in order to make the re-write rule work, that is: in order to make both input forms in fact equivalent.
Now the ATX heading syntax works with pretty much any value for {string}: it may contain arbitrarily many NUMBER SIGN characters, even at the start or end (see example 40), or start with “>⎵”. In fact, I see no other restriction for {string} than that it must not straddle input lines.
In contrast to that, the setext heading syntax description has a whole paragraph of restrictions on {string}:
[…] a line of text, containing at least one non-whitespace character, with no more than 3 spaces indentation, followed by a setext heading underline. The line of text must be one that, were it not followed by the setext heading underline, would be interpreted as part of a paragraph: it cannot be interpretable as a code fence, ATX heading, block quote, thematic break, list item, or HTML block.
For my taste too, the syntactic side-conditions for {string} in ATX headings are so much weaker than those applicable in setext headings that one can in fact ask why this is required.
It seems that the weakest possible requirement on {string} in setext headings would be that {string} is not blank: that is, contains a least on graphical character.
It would then be IMO appropriate to require the {string} line and hence the setext heading to be preceded by a blank line (which I would consider reasonable anyway). Consequently, when parsing CommonMark, recognition of a line following a blank line as (the starting line of) a:
- code fence,
- ATX heading,
- block quote,
- thematic break,
- list item, or
- HTML block
would be “suppressed” iff the next line is a setext heading underline.
Algorithmically, this would require only look-ahead over one input line, and would only be executed in the transition from blank lines to block of non-blank lines.
In this way, the “rewrite rule” would in fact “always” work—except in the “degenerate” case when {string} is a null string, or consists of white space only. But it seems that this exception can not be avoided in order to still allow recognition of a thematic break (formerly known as <HR>, or harsh rupture 
) comprising only HYPHEN-MINUS characters.