People use closures for security-sensitive stuff like restricting DOM access for third party scripts by forging properties on
Date.now() to disallow side-channel opportunities, and so on. If you don't trust the code that calls it to not muck with internal state and screw with your internals, closures help here. This isn't theoretical - malicious tracker scripts are a thing, and they have a knack for reading
<input type="password"> fields without prejudice on the open DOM. As for how they get there, the site developer is rarely told about this, and often the immediate vendor has no idea, either. Instead, it's a malicious actor gaining access much further down the supply chain, like the
event-stream issue but on steroids. This is one of the largest sources of data breaches, and it's fairly well-documented and you could easily find out more in a Google search.
It's one thing if an implementor chooses to expose closure data for inspection, but it doesn't belong in the spec and most certainly won't find much availability in browsers. We've been bit too many times with malicious actors to not be at least moderately conservative when it comes to security, and you can see this even in the HTML spec in parts.