Let me expand on the post just a little. Someone above requested the technical background so I'll try to include some of it here also. The reasons for removal are basically 3-fold:
It masks issues in the service:
Performance / Hardware / Environmental issues - if there are issues with a particular database or server and for some reason our monitoring fails to detect it: If customers move their mailbox for troubleshooting in this scenario, it could fix their issue, but how many more mailboxes are still on that database/server that are impacted? Additionally, if it's a performance issue, your move will likely be heavily throttled on the source side and not be able to move anyway. If the move finally is able to complete, it is probably because the load had already been reduced by our other self-healing processes inside the service, which means the issue was probably already resolved before it completed and it gives you a false sense of accomplishing something.
Software Issues - new software versions deploy in Exchange Online continuously, we do our best to be bug-free, but there is the occasional problem that needs to be addressed. If you are affected by some issue caused by a software update, moving your mailbox to another server might temporarily provide some relief but it is likely to come back very soon when your new server gets updated to the same version. If we don't know about a problem, we can't fix it.
It delays issue resolution:
Moves take a long time and they don't solve most issues. We're talking about tons of data in mailboxes these days. Moving a mailbox can mean moving up to 300GB of data with Primary + Archive + Recoverable items in both. This means moves today can take an incredibly long time to complete both due to the size and the fact that we can't prioritize these moves over critical things like mail flow and client access. If we wait for a move to complete every time we have a problem, we could be adding weeks or even months to resolving a problem. It is much better to get the problem to the right people so they can fix it permanently. That's why we're here; please let us know if you're having a problem so we can make the product better.
MoveRequests for local moves are difficult to maintain:
Exchange doesn't just store mailbox data anymore. That's right, we've got lots of data in Exchange mailboxes for services across the Office 365 suite of services. Most of this data is stored in mailboxes that are linked to users, similar to primary mailboxes and archive mailboxes, but not exactly the same. Internally our load-balancing machinery uses new technology that understands all these different types of mailboxes; unfortunately New-MoveRequest does not. New-MoveRequest for Exchange Online is intended for moving mailboxes into and out of Exchange Online from on-premises environments. Continuing to use New-MoveRequest for local moves would create a situation where customers executing local moves are the only ones running some of this code; this makes it very easy to introduce bugs. Bugs in moves are scary, because they likely result in data loss. Instead, we will limit New-MoveRequest to onboarding and offboarding which it knows how to do well, reducing the likelihood of introducing bugs that result in potential data loss.