SecureBoot uses an existing certificate implementation which supported expiration, for a scenario where a having a reliable clock in unfeasible.

SecureBoot would have been better off with certificates that never expire. That's not a problem in cases where users (or organisations) manage their own hosts, since they can just changed the certificate when the previous one is no longer valid or leaked or whatever.

In practice, SecureBoot rolled out with a single CA for everyone, one controlled by Microsoft. This provides little value for anyone—restricting your computer to "only boot stuff signed by a third party" doesn't really protect from attackers in any way. They'll just boot into one of the many programs signed by MS. But because a single CA is used globally, you want expiration so as to roll them over every few years. But remember: there's no way to have a reliable clock. And so, we have the mess that we have.

The grand majority of Linux users could disable SecureBoot tomorrow and their system's security would not change in any meaningful way.

Was Secure Boot supposed to increase security? I thought Microsoft was using it to make it near impossible to install Linux

The rollover coincides with stronger security policies for signed objects (enforcing code being read-only, that kind of thing) and people with stronger security requirements can remove trust in the old certificate to enforce that.

Code has bugs. There's any number of critical vulnerabilities in Linux, Windows, MacOS that have allowed bypass of all security features - does that mean all security features remain security theatre?

They clearly didn't want to leave a system unbootable because a certificate expired. In which case you would have no opportunity to update the certificate because you can't boot the system anymore.

They could've used a time stamping service to include a signed timestamp in the binary to compare the expiry date against, but that still leaves the system unbootable after the time stamping certificate expires in the far future.

Besides, a hacking group powerful enough to steal Microsoft's Secure Boot private key will likely be able to steal a timestamping private key from a certificate authority as well.

With the default key hierarchies, the benefit is more limited. It raises the bar. Implementing known vulnerabilities takes work. And not ever configuration is vulnerable to every issue. And, for a lot of the vulns, the OS vendor shoves things in the dbx to mitigate.

With custom hierarchies, it's a bit more compelling. But it's a lot of work to maintain.