>> Decades of intrinsic knowledge. Which a rewrite lacks.

You mean the ones encoded in the regression suite? I think your argument is valid in many medium-to-faang firms where the application is going to have encoded business logic that isn't explicitly tested for. If anything, projects like PG are the exact opposite: no business context and regression suites that test every possible scenario due to the accumulation of bug fixes and context over many years.

>> Run it in production for a year in a sufficiently large system and you might be somewhere.

How do you know every release of PG doesn't break in the setting of "a year in a sufficiently large system"?

> no business context and regression suites that test every possible scenario due to the accumulation of bug fixes and context over many years.

Spend time enough with a codebase and you’ll know stuff about its behavior that is not encoded in a test suite. Especially when you need to adjust an integration tests due to the modification of an invariant in a dependency.

> How do you know every release of PG doesn't break in the setting of "a year in a sufficiently large system"?

Because the postgres team is professional and will take care of publishing a changelog for what has been modified since the last version.