Isaac, you might not be old enough to remember this. But I am.
In classical BASIC circa late 1960s, you could dynamically create variables without first declaring them with a DIM statement. It didn't matter so much back then because the language was fully interpretive INCLUDING VARIABLES! Didn't matter how you used it, every variable was a Variant even though they did not name it as such. As time passed, stronger-typed languages became the vogue. BASIC took the simple way out and allowed static type declarations. In compiled languages, because you have to implement type-specific hardware instructions, you CANNOT take the dynamic variant approach to its limits. All variables have to be type-declared before you can compile instructions that would reference them, because otherwise the wrong instruction would be used and you would have a bad result. In fact, the ONLY machine I ever saw that didn't make a difference between LONG and SINGLE was a Honeywell 4800 because they used a bizarre floating-point format. All other machines delineate between integer math and floating math. Since strings are actually just implicit arrays of byte integers, that issue of instruction types applies to strings too. And we can't forget that not only do we have a difference between string vs. integer vs. floating point, but the sizes of integers and of floating point items ALSO can be different. We have BYTE, WORD, LONG, and LONGLONG (or QUAD, depending on your version of VBA) for integers and SINGLE or DOUBLE for floating-point. And again, the compiler has to know that you are using ahead of time to be able to build the right code.
VBA allows the "old" behavior because you CAN leave off Option Explicit and just name variables without regard to data typing. But to allow for more usage of strong-typing principles, VBA also allows Option Explicit so that you can let the compiler catch type-assignment errors. Now here is where you run into issues with what you said.
VBA is a semi-compiled language. It is not interpreted. Instead, it runs as a PCode emulator, where PCode is the instruction set of a hypothetical but well-defined virtual machine. VBA compiles PCode from your module content. When you use DIM X AS STRING, you have in fact declared an item to statically be a string. It will contain a string-descriptor. It is not a variant at any time, because remember this: You can get compilation errors such as Type Mismatch even before you run the code. Declared types are NOT dynamic EXCEPT for Variant types. Whenever you have a type conversion of ANY kind, it is because the compiler noted that a specific data type was used that required conversion, so extra conversion instructions were compiled into the sequence.
Now, as to whether there is a speed difference between, say, TRIM() and TRIM$(), I don't know for certain because Microsoft, in their infinite wisdom, does not give us insight into the PCode compiled for a particular code sequence. However, if I declare a string variable and then assign TRIM$(x) to that variable, the compiler will recognize that a conversion is not required for that case, so won't include conversion code. The speed difference is that a variant data type has a descriptor even for numeric data. But it is not clear that other data types DO have descriptors.
You may ask how I am so sure. If you web-search VBA LANGUAGE SPECIFICATIONS you can find a few good articles that even define when type conversion code will be implemented. Be warned, however, to bring lots of strong black coffee if you really want to start reading that much.