Update: behavior described in this blog post has changed in later Cumulative Update; please see Remote PowerShell Proxying Behavior in Exchange 2013 CU12 and Exchange 2016.
Coming to the next CUs ...
Updated Jul 01, 2019
Version 2.0
Blog Post
Instructions to load PSSnapin for Exchange in the local PowerShell session are already in the Exchange 2013 documentation:
https://technet.microsoft.com/en-us/library/jj150489%28v=exchg.150%29.aspx
https://technet.microsoft.com/en-us/library/jj150489%28v=exchg.150%29.aspx The instructions are right below this caution: "Loading the Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell snap-in and running cmdlets other than the *-TransportAgent
cmdlets is not supported and may result in irreparable damage to your Exchange deployment." I guess the documentation needs more updating.
My biggest concern is about the effect of this change in multi-site environments and the impact on performance.
"In previous versions, we have seen that customers who were reliant on a load balanced solutions for third party apps and scripts may get routed to a non-Exchange 2016 server."
At this point I'm not sure if I understand why this change was necessary. It introduces quite a few new interesting challenges to fix an issue that could've solved with one page of documentation on how to configure your environment with load balanced PS access.