However, what *is* important about what Satoshi wrote is that it is sort of the "social contract" of what Bitcoin is that we can all sort of minimally agree to. This makes it clear, when we try to describe Bitcoin with differing assumptions than in the whitepaper, what the changes are and why we think the system might support those claims. But if we can't prove the new description sound, such as showing tip mining to be rational in a fully adversarial model, it doesn't mean Bitcoin doesn't work as promised, since all that was promised originally is functioning under an honest majority. Caveat Emptor!
I still think it is misguided to think that the "honest" (i.e. rule following) majority is to just be accepted as an axiom and if it is violated, well, then sorry. The rules need to be incentive compatible for the system to be functional. The honest majority is only considered an assumption because even if following the rules were clearly the 100% dominant strategy, this doesn't prove that the majority is honest, since mathematics cannot say what is happening in the real world at any given time. Still, we must have a reason to think that the majority would be honest, and that reasoning should come from an argument that the rule set is incentive compatible.
The stability of mining, i.e. the incentives to mine on the most work chain, is actually a huge concern, especially in a future low subsidy environment. There is actually much fretting about this issue, and rightly so. We don't actually know that Bitcoin can function in a low subsidy environment because we have never tested it. Bitcoin could still end up a failure if that doesn't work out. My current understanding/guess is that with a "thick mempool" (that is lots of transactions without large gaps in fee rates between them) and/or miners rationally leaving behind transactions to encourage mining on their block (after all it is in a miner's own interest not to have their block orphaned), that mining will be stable. But I don't know this for sure, and we cannot know with certainty that we are going to have a "thick mempool" when it is needed.
It is most certainly the case that one can construct situations where not mining on the tip is going to be the prefered strategy. But even if that happens on occasion, it's not like the protocol immediately collapses, because mining off the tip is indistinguishable from being a high latency miner who simply didn't receive the most work block in time. So it is more of a question of how rare does it need to be, and what can we do to reduce the chances of such situations arising (e.g. updating our mining policy to leave some transactions out based on current (and anticipated) mempool conditions, or (for a sufficiently capitalized miner) leave an explicit, ANYONECANSPEND transaction output as a tip for the next miner to build upon mined blocks.)