It's all about subtypes. In vbscript, everything is a subtype of the 'variant' datatype. So this:
Dim MyDouble, MyString
MyDouble = 437.324
MyString = MyDouble
would subtype 'myString' to be of subtype, double, since you have assigned it a numeric value. Notice no quotation marks. So even though you have named the variable 'myString', it's not a string at all. It's a number.
The single best explanation I saw here was from codestorm:
Often useful for making sure you're comparing two strings, or to make sure you're passing a string into a Parameter object that expects one.
If you have a stored procedure that expects a string value:
@someString varchar(20)
and you send it this:
dim someNum
someNum = 6.54
commandObject.parameters("@someString"

.value = someNum
you will get a runtime error every time.
On the other hand, if you send it:
commandObject.parameters("@someString"

.value = cstr(someNum)
you will receive no such error.
Your observation:
c = a & b
resulting in string concatenation is, in fact, true. But that has to do with your use of the concatenation operator, and so vbScript is 'smart' enough to know what you are trying to do. However, it's going to result in a slower operation than doing this:
dim a, b, c
a = "a"
b = "b"
c = a & b
Because the concatenation operator is native to the string subtype, it will go faster, since there's no implicit call to cstr, which there is in your example.
Because of these types of nuances and such, it's hard to understand why you would want to cast (cint, cstr, clng, etc..) variables to their respective types. But if you don't you lose performance, and when you're on the web, performance is EVERYTHING. The more you let vbScript do for you (rather than doing something for vbScript), the slower your application is going to be.
ASP.Net is going to enforce this even further through the available use of C# in your web applications. Your applications will have the ability to run much much faster through the use of managed code. C# (the next generation of C languages) doesn't make it so easy on you when it comes to data types. It forces you to use them correctly, where VBScript does not.
hope that clears it up a little.

Paul Prewett