Thanks @cameel for all these. Insightful and precise.
Just to add the background of these discussions here so that a more complete picture can be put together.
My first impression about Create2 came from this blog post that has a fairly in-depth discussion on this topic and mentioned an alternative upgradeability pattern:
As a side note, by this point you may have noticed that having a reproducible deployment address allows you to deploy a new contract where an old one was self-destructed. You can deploy a contract, self-destruct it, and then use the same nonce to deploy again to the same address. This opens the door for alternative upgradeabilty patterns, which are explored in depth here.
Since this pattern would take the creationCode of a contract as an input, my first reaction is this could be used to upgrade any implementation contract directly.
And with the experiments on creationCode shown above, it is clear that creationCode can be easily changed. Therefore, this cannot be used to change any logic contract directly.
Given this, it is also clear that if Create2 were to be used in an alternative upgrade pattern, it must be somehow used with other contracts together. Otherwise, it makes no sense to selfdestruct a contract and deploy a contract to the same address with exactly the same creationCode, which depends on not only what is in a constructor, but also what is not in a constructor (as indicated by the public mapping example above, and all other discussions on the mechanisms of how a constructor works).
And the way of having Create2 work with other contracts to create an alternative upgrade pattern is beyond this thread and would be another topic if there is any issue.