Because status pages are now pages that express politics regarding SLAs for executives and lawyers rather than useful technical tools for developers and sys-admins.

I've seen this behavior at every place I've worked. You get in trouble when the status page goes red, therefore never say that anything is down unless you absolutely have to do so.

One pessimistic argument would be that AWS has no incentive to be honest or timely about acknowledging service outages.

In order for status pages to be useful, they need to be hosted externally, with no dependencies on the product/system/company they report on.

They're already fairly hard to automate, but making them external makes it even harder. So they're generally not automated. And, hopefully, they're not exercised very often, so they're often forgotten. The best way to manage this, IMHO, is to enable customer service to update the status page and delegate the duty to them. Generally, updating the status page reduces the customer service demand, so CS gets the most direct and timely feedback and is best placed to manage it.

Source: I ran a status page, poorly. It wasn't fully external either, but was far away from all the moving parts, so it would only have correlated failure if our hosting had a multi-site routing issue (which happened once, but not while I was there) or DNS problems, but we had mitigations for DNS not working in the clients, so not too bad.

Internal politics. Anecdotes are that org leaders face potentially serious consequences if the products they’re responsible for are down per status page. So they find ways to cover it up. This culture is passed top down as everyone is incentivized to downplay widespread outage.