One of the ways in which writing reliable software for SharePoint Online differs from previous versions of SharePoint is all the extra redundancy that has to be built in. It's a little like writing software for a space mission, deployed in an environment where it can be subjected to many types of failure and must adapt. Every action needs at least two ways of accomplishing it in case the first one fails. It helps that one of our programmers did write software for NASA.
This is because SharePoint Online does not always fully load a new page, but rather it often simulates transitions from page to page without fully wiping out the current page DOM and page data in the browser. These transitions, as well as the use of caching including caching of API calls, mean that some events that are normally triggered when loading a fresh page are not necessarily triggered when navigating to that page from another page.
In addition, some of the state information in the APIs is not necessarily correct; it might be a state that was cached from an earlier page even though the state has changed. Add to that the asynchronous nature of so much of the API, where API calls can return in a different order, or with an error, or not at all, or worse still with missing or invalid information, and you need to build in a lot of fallback strategies.
Finally, Microsoft reserves the right to change master pages and other features unexpectedly, which makes a lot of software fail if it makes assumptions about page layouts or authentication, or even about the simple process of following a hyperlink. Redundancy is required because changes can occur without warning.
Don't get me wrong, I love the new SPFx and the way that it can execute quickly, before most of the page appears, rather than waiting until the entire page is loaded before running your code. It's just that you can't assume that it has done its assigned tasks properly, and you have to check on its work and be prepared to re-do it later on in the page life cycle.