Stale DNS and the "async DNS" resolver have had success at improving the reliability and latency of DNS in many circumstances.  However significant instances of ERR_NAME_NOT_RESOLVED are still not ameliorated by these two optimizations.  See internal bug b/29525886#comment134.  I think ERR_NAME_NOT_RESOLVED can come from a few different things:

1. The host isn't resolvable.  So a DNS server would return NXDOMAIN.  This is known to not be the case in the instances we've been monitoring however.
2. A device-local problem, such as lack of an Internet connection.  Generally these errors should be translated to ERR_INTERNET_DISCONNECTED, but the transition to ERR_INTERNET_DISCONNECTED is one tuned for few false positives, so in turn a connection that isn't fully completed or in the process of disconnecting could imaginably fall into this category.
3. The ISP's DNS server is misconfigured or broken.

In cases #2 and #3, if stale DNS results are available, using them is preferable to simply failing with ERR_NAME_NOT_RESOLVED.  At the very least experimenting with use of stale results in these cases should shed more light on the problem by giving more informative error codes (ERR_INTERNET_DISCONNECTED if device is later determined to actually be offline during TCP connect, ERR_TIMED_OUT if the Internet connection is broken, etc).