One problem with the recommended solution (when keeping the EXO mailbox), and this would be true for anytime you're keeping the EXO mailbox, but users' Outlook profiles are using the on-premises mailbox - new Outlook profile is required because the ExchangeGuid of the mailbox is going to be different.
 
I think I'll submit a pull request for the linked docs page to add a note about this.  If/when I do, I'll also add the use case which I think is the far more common one - that the problem state is reached by Exchange Online provisioning a new mailbox upon the EXO license being assigned prematurely.  The opposite (where Exchange on-premises creates a new mailbox), I've never seen that happen.  I get that it could, but it would be extremely rare in comparison to the scenario where EXO creates the 2nd mailbox.
 
I still think there's room for improvement in EXO around this problem.   For example, there could be an option added to OrganizationConfig to disable automatic mailbox provisioning upon license assignment.  It's too common that this issue comes up.  MS Support's first line is NOT ready for this problem.  It's true that customers should not assign EXO licenses to newly created users until after they've done Enable-RemoteMailbox (or New-RemoteMailbox / new > Office 365 mailbox in the GUI), and then waited for 2 AAD Connect sync cycles to pass, but the likelihood that many customers will continue to make this error is very high, and time has proven this.
 
Recommending pre-licensing is not a safe idea to me.  The example reason given, to avoid the mailbox being deleted immediately after migration - that just reveals how the 30-day grace period, sometimes it just doesn't happen.  Pre-licensing would avoid that, yes, but it will also tee up 10's/100's of 1000's of customers to pre-license prematurely (PPL - new term!).