So why doesn't Microsoft Deployment Toolkit 2008 use PowerShell scripts during an OS deployment?

It seems to be a common question:  Why does MDT 2008 still use VBScript during OS deployments, rather than moving to something more "cutting edge" like PowerShell.  So let's review a few reasons:

• You probably don't yet want to use PowerShell in your old operating system.  Imagine if we shipped a solution that said "before you can upgrade your machine from Windows XP to Windows Vista, you first need to deploy .NET Framework 2.0 and PowerShell 1.0 to all of your XP computers."  Deploying these technologies to an OS that might not yet have them, when you are then just going to wipe that OS to install a new OS, adds an unnecessary burden.
• PowerShell isn't supported in Windows PE because Windows PE doesn't include .NET Framework support.  So any scripting that we have to run in Windows PE can't be written in PowerShell.
• PowerShell isn't supported in Windows Server 2008 Server Core, as Server Core doesn't include .NET Framework support (and therefore no PowerShell either).  We don't want to have to create a PowerShell script that would run on Windows Server 2003 or a full install of Windows Server 2008, but then create a VBScript to run on Windows Server 2008 Server Core installation option.
• IT administrators are still much more familiar with VBScript than with PowerShell.  We want you to be able to read the scripts, and make modifications if necessary.  (This is the same reason we don't just convert it all to C++: we want you to be able to understand it.)

As time goes by, PowerShell will become more and more prevalent, so we'll revisit this periodically.  At this point, it's safe to say that your VBScript knowledge will serve you well for quite some time.

Now, supporting PowerShell on the MDT/ConfigMgr server (for configuration of task sequences; importing source files for apps, OSes, drivers, patches, etc.; populating databases; etc.) makes much more sense, so we are investigating what additional PowerShell support we can provide there.  (You can do some things now, as our server-side components are written in .NET.)  There is nothing committed at this point, though.  If you're interested in something like that, please let me know.