First, let's define what a Local Runspace is and how that differs from the one you would use for Exchange 2010. A Local Runspace is a runspace configured to load the local Exchange Powershell snapin via the RunspaceConfiguration object. This was the standard type of Runspace created when automating Powershell with .NET in Exchange 2007. The runspace would execute all cmdlets in the command pipeline on the machine in which the application hosting Powershell ran. By default, the cmdlet's would run in the security context of the launching user of the process hosting Powershell.
In Exchange 2010, we now have the ability to remotely administer an Exchange server from the comfort of our Windows 7 client machines without any additional management tools installed! This is done through Powershell 2.0's remoting behavior. It is now possible to have a PSSession that is controlled locally but the command pipeline is executed remotely.
If application developers want to execute Exchange cmdlet's in their application, they now need to establish a Remote Runspace before attempting to execute their command pipeline. I have a sample of this already posted and you can read about the sample as well. Or you can look at the samples published by the Powershell team too.
This is an important topic because developers who have developed applications for Exchange 2007 using Local Runspaces will not be supported on Exchange 2010. This is because Local Runspaces are not supported for Exchange 2010, you must use Remote Runspaces. Also, the snapin for Exchange has been renamed in Exchange 2010 so a developer would need to recompile anyway to get this to work on 2010.
Here is a side by side comparison of a Local Runspace and a Remote Runspace in the context of Exchange 2010:
[Edit: 3/7/2013] Important Note: If you are using Exchange 2013 and transport agents please see my related post.