I don't understand what you're trying to say. I'll rephrase my position in longer form, because I think we're talking past each other.

High level APIs necessarily make a lot of assumptions of how the low level details should work. When successful, users can get 80% of the benefit of the ideal low level implementation for 20% of the effort.

For complex apps that 80/20 tradeoff isn't worth it, they would rather spend the extra effort to get maximum utility out of the API, even if it means mucking about with low level code.

(As a non-web example, consider filesystem APIs. Most apps use just a few filesystem APIs, they just want to read strings, write strings, and list files in directories. A few apps though, like databases, can get huge benefit over having finer grained control, and need lower-level filesystem APIs.)

App Cache is an example of trying to build the high level 80/20 solution first. It looked reasonable, but it failed in the details. You can't build a good low level API out of a high level one, but you can build high level APIs out of low level ones.

Service Worker and Web Components take the opposite track. They are lower level APIs, sufficient to make complex apps possible. Library code can come in and build on top to provide high level 80/20 solutions. Then, after looking at the libraries that people build and use, we can pave the cowpaths and standardize good high level APIs.