There are a couple of thing missing in your list, and those are quite important:
Number of requests needed to load all your assets, latency and blocking.
Browsers only load limited number of assets in parallel, so if you have a lot they will wait. Latency makes things bad (especially on mobile), but in case you have a lot of assets it makes it even worse. Also, keep in mind, that most often it is the latency that kills the speed of the loading. It does not really matter if it takes 20 or 60ms to download your asset if the latency is 10x that.
Blocking: your #4 is not exactly right, browsers can start rendering the page at once, but if you try to load scripts first they will block rendering. Hence the importance of understanding where to request your css and js and how to load them.
Agreed, my list was more of a general view of the whole process. Asset latency, blocking and requests all fit in Page Rendering in my mind. Actually, DOM processing and Page Rendering are very closely related.
Actually, using your logic, #4 is right. I worded it wrong, "Only done after all the "assets" are downloaded" should be "Only completed after all the "assets" are downloaded". More often that not, you'll see high (6 seconds+) Page Speed scores because Page Rendering isn't completed due to missing or slow assets.