tldr: It's easier to declare `hook_civicrm_buildAsset` listeners at a high-level.

Asset building can use two modes -- production mode writes a static file to
disk when it's being reference.  Debug mode just generates a URL for a
web-service (which in turn dynamically renders the content in a separate
page-view).

If the only mode were production mode, then the code would be on pretty
solid ground.  We could even simplify things a lot by changing the
AssetBuilder contract to replace the hooks with callbacks, as in:

```php
Civi::service('asset_builder')->getUrl('crm-menu.css', function() {
  return '...the css code...';
});
```

Why have a hook?  Because hooks are generally context-free and
always-available.  If we use debug-mode (or if we add a feature to warm-up
the caches during deployment), then we'll want to fire that hook from a
different context (e.g.  web-service or CLI), and the hook-listener needs to
be available in those other contexts.

It would be nice if we could declare hooks generally without needing to edit
the `Container.php` mega-file (e.g.  maybe some kind of annotation).  But,
for the moment, I think this is the best spot that we have in `civicrm-core`
for ensuring that hook listeners are fully/consistently registered.