Requirements 3.6 and 3.7 include prevention of active MITM attacks. The TLS ESNI supposedly "solves" the problem by shifting the problem to DNS. But the problem of an active MITM attacker isn't actually solved by DNS. Per the TLS ESNI RFC:

  7.1.  Why is cleartext DNS OK?

  In comparison to [I-D.kazuho-protected-sni], wherein DNS
  Resource Records are signed via a server private key,
  ESNIKeys have no authenticity or provenance information. 
  This means that any attacker which can inject DNS responses
  or poison DNS caches, which is a common scenario in client
  access networks, can supply clients with fake ESNIKeys (so
  that the client encrypts SNI to them) or strip the ESNIKeys
  from the response.  However, in the face of an attacker that
  controls DNS, no SNI encryption scheme can work because the
  attacker can replace the IP address, thus blocking client
  connections, or substituting a unique IP address which is
  1:1 with the DNS name that was looked up (modulo DNS
  wildcards).  Thus, allowing the ESNIKeys in the clear does
  not make the situation significantly worse.

  (https://tools.ietf.org/html/draft-rescorla-tls-esni-00#section-7.1)

So there is no solution possible per the original requirements, which the TLS ESNI specification admits. (See above.) All the existing TLS ESNI specification does is obfuscate the issue at the expense of considerable implementation complexity.

DANE never gained traction because wedding TLS to DNS was considered intolerable from the perspective of both client-side and server-side implementation complexity. But apparently not intolerable enough when it benefits centralized hosting providers. Indeed, it's not intolerable client-side complexity because unlike DANE they're not going to bother trying to implement DNSSEC browser-side; instead they're going to farm that out to a hosted service. (Remember Mozilla+Cloudflare mentioned several weeks ago? Nominally free, but as with all business strategies, if you're not the customer you're the product.) And server-side they'll just bill directly for the cost of the complexity, because now there's even more incentive for the big hosting providers to maintain your DNS for you. (Of course, in reality they'll just siphon business away from the traditional DNS registrars, so the customer sees "value-add" while the entire internet continues to centralize even further.)

What TLS ESNI is, is the realization that people killed DANE because they let perfect be the enemy of better. (Where better is to just assume DNSSEC is already solved outside the browser, or more generally depending on DNS solving the hard part, and solving it in a way that minimizes browser implementation complexity.) But apparently nobody is yet willing to cop to that reality.

TLDR: The proper solution is a simpler one that achieves the same degree of privacy--fix TLS to setup an ephemerally-keyed channel first, then perform domain authentication by exchanging data within the channel. If you don't have to worry about preventing an active MITM attacker from snooping domain names, then you don't need a committee to draft up a spec. The requirements RFC says we do have to worry about an active MITM attacker, but the actual TLS ESNI doesn't actually prevent that. It just redefines the scope to "solve" the problem away.

[1] You could argue that it's easier to MITM TLS than it is to MITM DNS, but nobody is going to buy that argument.