I would also add that the "long term goal" is to standardize the events from the UX perspective. Right now most of the events we have in apps are aiding developers in measuring app loading stages from their perspective ('startup-path-complete', 'db-loaded' etc.).

Those stages do not help us establish perceived performance, which is revolving around questions like:
 - when will the user see app chrome
 - when will the user feel that the app loaded (i.e. things stopped changing on the screen)

This in turn may aid is in a long term with making the events aid our platform (be it System app of Gecko itself) in optimizing around better UX. For example:
 - we could start blocking moving the app to foreground until moz-chrome-dom-loaded which, combined with firstPaint/onload, would make us deterministic about no-FOUCs
 - we could deprioritize/suspend all other apps/services between app-launch and moz-app-visually-complete to help get the app started faster
 - we could postpone screen events bubbling to the app until moz-chrome-interactive

It's just a few of the possible implications.