I would like to see the complete test environment.
I don't know what you mean by that - I'm not going to mail you my computer. The 'complete test environment' is an Access database, nothing more. You can easily make a blank one yourself, create a table, load it with the sorts of strings the OP described and make your own tests. If you do it with a pure SQL query, your results will be quick. If you put a call to a VBA function into the query, they will be a lot slower, and it will not matter in the least what the VBA function does.
If you do exactly the same thing and just add some overhead, you shouldn't be surprised if runtimes increase. This conclusion seems plausible to me even without testing.
Well, of course - that's my whole point. Calls to a VBA function add overhead, and apparently quite a lot.
The Expression Service only works if the query is started from Access. Jet-SQL can also be called from other places, via DAO/ADODB in Excel, VBScript & Co., but there is no direct access of the database engine to external commands. This makes it easy to test what is part of the actual language scope of Jet-SQL and what is not. You can use tests to test your beliefs.
I did test, and the results are exactly as I described, and exactly what I expected.
That's pretty much what I expected, although the second line also surprises me a bit. Is it possible that the VBA code is not compiled here and that the VBA commands are therefore constantly being reinterpreted?
No. The overhead is in the repeated calls to VBA. If you compile the code first, the results will not be materially different.
Regarding data types: If you break a string down into substrings, the substrings are also strings. You can only get something different if you also perform data type conversions.
Of course - who would expect anything else?
I prefer a solution using Split or RegEx because they are extremely variable. You notice this when you want to isolate the third or fourth subexpression instead of the second one. You only change one argument when you call the function.
Yes, no argument - calling a VBA function gives you lots more options. BUT, at the cost of a monumental increase in run time. If you have complicated requirements and only a few records, it's clearly the way to go. If you have simple requirements and many records, it is clearly a bad choice. The OP had simple requirements, I do not know how many records. But his specific request, copied directly from his original post is, "If this can be done in an expression written into the design view of a query, that would be most ideal as I am not great with VBA at all." THAT was what I was answering, and the fact that it is also MUCH faster is simply a bonus.