The expiry clause is interesting, but I'm not sure it matters in practice. Not many people want to use code several years out of date instead of the current version just because of practically no additional freedoms. Except maybe a potential competitor. I'd be happier to have a reversion to an OSI license if the product stops being maintained or gets acquired and shutdown. That's always a risk with young companies.
I am mainly looking to prevent the timescale corp. from coasting off of their long past work. In such a scenario, the several years out of date code would not be that much different from the current version, because income for timescale would not have been spent on meaningful improvements.
Another benefit is as a check to the timescale corp. in case they start acting up. In such a case, a large contributor or user might pick up maintenance of an old version and start porting it to newer postgresql versions as leverage. Users of TimescaleDB could be reassured that timescale will not abuse them through the licensing situation because there is some backup plan.
Your legal ability to apply patches to the software you run to better suit your needs, and in extreme cases to fork and continue development if the maintainers can't or won't accommodate your usecase. It's kind of the entire point of the open source movement.