That embeds a temporary hack in the application code indefinitely.
Or postpone the migration indefinitely. I saw so many times how migration in large companies was postponed because of similar "small" issues -- when the code base is large, it's easier for managers to say something like "no, we will better live without cool new features for a couple of more years than put our systems at risk due to lack of testing".
Nobody invented an excellent way to test production workloads in non-production environments yet. I know it very well because I'm also working in this direction for a couple of years. So this feature (a great one) seems to me as a major roadblock for DBAs and developers who would like to migrate to 12 and have better performance and all the new features. Ironically, including this one for the new or the updated code!
If you need to patch all your code adding "AS MATERIALIZED" (and you will need it if you want to minimize risks of performance degradation after the upgrade), then it's also a temporary hack. But much, much more expensive in implementation in large projects, and sometimes even not possible.
I do think that the lack of this configuration option will prevent some projects from migration for a long time.
Correct me if I'm wrong. Maybe somebody already thought about migration options here and have good answers? What is the best way to upgrade if you have dozens of multi-terabyte databases, a lot of legacy code and workloads where 1 minute of downtime or even performance degradation would cost a lot of money so it is not acceptable? What would be the good answers here?