Existing code might rely on this behavior, so if it changed some sites will stop working. Even if those sites were updated to the new behavior, browsers are not updated at the same time, so either way there would be a lot of breakage.
And some sites will never be updated because they are not actively maintained.
You drastically underestimate how much code depends on typeof null being "object". It’s extremely common in generic/library code. If you changed it to produce, say, "null", vast numbers of websites would completely break. As a simple example, a brief glance at the React and ReactDOM source code, inspecting the first few /typeof.*'object'/ matches, shows that in React, component.setState(null), and in ReactDOM, rendering class-based components with null state (which I’m guessing will be pretty much normal in existing code bases, even if it’s an older pattern now; but I haven’t ever used React seriously), would both throw an exception.
After asking the question, I looked for an answer and found the is-object npm package. It utilizes a null check to make sure a variable is an object. This utility has 6.6 million weekly downloads.
The logic in the isObject function will break because the second condition would then be invalidated. Resulting in a bad day for 6.6 million projects. It took me a while to digest the magnitude. Maybe because I just started as an SWE.