Consider a custom element that declares other custom elements. See, for example,  <polymer-element> (https://github.com/Polymer/polymer) which is similar to the deprecated <element> element.

It's common to want to place dependencies in HTML Imports. Consider this setup:

main document:
  <script src="polymer.js"></script> // registers polymer-element
  <link rel="import" href="x-a.html">
  <polymer-element name="x-b" extends="x-a">...</polymer-element>

x-a.html:
  <polymer-element name="x-a">...</polymer-element>

In this case, because HTML Imports are non-blocking, the import will parse after the main document and the definition for x-a will not be available by the time x-b wants to extend it.

Ideally, in the presence of HTML Imports custom elements would upgrade in the same order as if imports were blocking (e.g. polymer-element x-a upgrades before polymer-element x-b).

Although placing the script element after the x-a import would also address this use case, it would be unfortunate if this were required because it makes loading the import block parsing the main document.