VBScript is definitely fading, and PowerShell is rightfully gaining traction, but PowerShells

learning curve and backwards compatibility issues will keep VBScript around a bit longer.
VBScript was once unquestionably the preferred scripting language of most systems
administrators, offering them the ability to automate routine tasks and interact with Windows
features like IIS, Active Directory, and Terminal Services. Using the Windows Scripting
Host, VBScript performed tasks that the Windows shell (batch scripts) simply could not
handle. Then, in 2006, Microsoft released an alternative to VBScript and an extension to
the basic shell known as Windows PowerShell. Since then, VBScript has remained the
same while PowerShell 2 has been released.
Of course its always nice to have more options. At the same time, the existence of two
viable scripting languages poses some new questions for the budding admin. As we
compare them head to head, lets look a bit further into the benefits and drawbacks of each.

Functionality
Both VBScript and PowerShell offer similar feature sets. The difference between them is
more about how they actually acheive those features, and in most cases, PowerShell takes
the cake. VBScript utilizes COM components to access features while PowerShell is built on
top of .NET, meaning that it utilizes the base classes and is capable of interacting with
some applications (especially Microsoft ones) that cannot be manipulated via VBScript. In
fact, the folks who developed Exchange 2007 actually built the entire management console
using one-line PowerShell commands (called cmdlets) that do the dirty work for you behind
the scenes. Because VBScript is now deprecated and does not respect .NET functionality, it
is usually difficult or impossible to manage a .NET application like Exchange via VBScript.
Intuitively, one might think that PowerShell should blow VBScript out of the water in terms of
performance given the fact that PowerShell is integrated with the kernel and VBScript
relies on a COM interpreter. In reality, however, PowerShell and VBScript are roughly the
same in terms of efficiency. We can speculate about why this would be the case perhaps
the added overhead of .NET roughly offsets the inefficiency of using COM components
but the bottom line here is that performance should not be a consideration when choosing
between VBScript and PowerShell.

Compatibility/Deployment Readiness

The Windows Scripting Host dates back to Windows 98, so VBScript can be deployed to all
of your Windows clients out of the box. On the other hand, PowerShell was released in
2006 and requires at least Windows XP. More importantly, it is not included in Windows
distributions predating Windows Server 2008 and Windows 7, so you will need to deploy
and install PowerShell on all of your XP, Vista, and Server 2003 hosts before you can get
up and running with it. Perhaps you will want to use a VBScript to automate this process!
In many cases, PowerShell simply cannot perform all of its functions on pre-Windows
Server 2008/Windows 7 systems. For example, the Active Directory module an important
one for most systems admins requires Windows 7 and/or Windows Server 2008 R2. This
can be a real deal-breaker if your architecture utilizes Windows Server 2003 or XP clients.

Learning Curve/Existing Scripts

For starters, we should be clear about one thing: VBScript is a scripting language. While
PowerShell can be used for scripting, it is primarily meant to be a shell. So, if you are
already familiar with a scripting language or Visual Basic, you might find VBScript quite
easy to learn. If you are not a developer and have never used a scripting language before,
you might find VBScript a bit harder to learn, but there are still resources and existing script
libraries out there to help you get started on your first scripts.
Unless you are already familiar with the .NET base components, you will probably find
PowerShell much more difficult to learn. This is not to say that PowerShell is not accessible
its just built on top of a larger framework and thus has a moderate learning curve
attached.

Security
The Windows Scripting Host has gotten a bad rap over the years for being what Wikipedia
terms a vulnerability vector. In years past VBScript could be executed through Internet
Explorer and bad actors of all varieties would use VBScript to execute code at a high level
of system privileges. PowerShell can use digital signatures (code signing) to prevent
execution of malware, something that VBScript does not off
https://4sysops.com/archives/vbscript-vs-powershell/

VBScript is quite limited in what it can do compared to PowerShell. PowerShell has access to all .NET
libraries so you can take advantage of anything you could with a language like C# or VB.NET. You can
also load any .NET DLL and take advantage of third party libraries such as those found on codeplex.
PowerShell has some limitations, but you will rarely run into them. Powershell runs on a single thread so if
you try to invoke any .NET libraries that create a new thread like BackgroundWorker you will have issues.
That said, you can't do any concurrent processing with VBScript. In PowerShell you at least have
background jobs.
PowerShell is also interactive. This allows you to try out things at the console first and integrate them into
larger more complicated scripts.
There are also a number of free development and debugging tools available for PowerShell. It comes with
one actually called the ISE. Another one is available from Quest called PowerGUI. If you want something
similar in VBScript you'd have to use something like Visual Studio and launch your script with cscript
//X or use something like PrimalScript which is expensive.
PowerShell often allows you to do more with less compared to VBscript. In some cases you can reduce
VBscripts that are hundreds of lines to just tens of lines in PowerShell.
If you find yourself reading a BASH script at some point you might be surprised how familiar it is after
having picked up PowerShell. The syntax is similar. Also it's easy to convert PowerShell code to C# and
visa versa. This is great because if you can't find an example of how to do something directly with
PowerShell you just may find an example in C# and it can be converted to PowerShell fairly easily.