Everything you said applies to humans using normal web browsers as well. And yet people still fill pages with JS, and browsers still execute it, and people still see stuff.
With one minor difference: Humans at least have full-blown human intelligence which they can use to heuristically determine when the execution is "complete". Not that that makes all that much more sense ...
You seem to be saying that page load is not deterministic but that is not true. A special version of a browser can easily keep track of http requests and other async operations and consider the page to be complete when async ops = 0 and the last paint is complete. The only hard part I can think of is a page that is recursively calling setTimeout endlessly, but even that can be coded around.
Right, so like you said they have a reasonable cut-off for this one most likely ultra-rare situation. It's not going to be perfect but it doesn't have to be, in order to be useful.
Yeah, that does make it better, but it's still not perfect. Witness the complaints right here about how you can't tell whether you got an empty page or it just hasn't finished loading yet.
Trouble awaits when you try to wedge a general-purpose application environment into a page-based document viewer.
I doubt Google is worried about unfairly weighting pages it indexes with Javascript that takes so long to run, hence the cutoff. It's more a question of where to place the cutoff than whether to have one at all, which is absurd.
No, the question is neither of those. The question is how to define the cutoff in a portable way that enables interoperability and long-term stability. A document format where every implementation has its own secret cutoff that also probably changes all the time is just idiotic if your goal is interoperability.
