marketingCloudServerSecure: "INSERT-SECURE-TRACKING-SERVER-HERE" // same as s.trackingServerSecure
In practice, DTM abstracts that away into _satellite.getVisitorId() and returns visitor, so that is what you get from the _satellite.getVisitorID() method. If you're going the "vanilla" route (shown in original post), this is the missing step from the original link that actually defines visitor (which, incidentally, is now a 404 page. Someone decided to change some underscores to a hyphens in doc url taxonomy, and broke a lot of doc links... Here is the current working link: getMarketingCloudVisitorID). So this part is the DTM specific syntax.
From there, getMarketingCloudVisitorID() is a method of the Visitor "class" (object), which is the Marketing Cloud ID Service tool's syntax, which returns the actual marking cloud visitor id (what you see in the AMCV_XXX cookie, or from the mid= param in the AA request).
So _satellite.getVisitorId().getMarketingCloudVisitorID() is "complicated" because it is chaining two methods from two different tools together. And it should work if you implement the marketing cloud visitor id service as a tool in DTM.
As for why they couldn't provide a shortcut like _satellite.getMarketingCloudVisitorID(). Personally, I don't really see the big deal about this. An extra method call thrown into the chain isn't some kind of earth shattering rocket science for anybody who codes on the regular. Better to break it out into conditions to check if the methods exist instead of chaining them. Or at least wrap in a try..catch. Regardless, all of this is coding 101 level stuff.
Also, the Visitor object has a lot more uses than just returning the mid= value, so it makes sense that DTM should have a method that returns the full instance of the Visitor object. And at that point, making "convenience" functions for specific things becomes a question of how tightly you want to couple two tools together. Best practice is to make coupling as loose as possible, to maximize flexibility. Granted, one of the most common use cases for all of this, is getting the mid= value. But, it's not all that common for implementations to require it to begin with. I have dozens of clients on marketing cloud id service and only a few of them require this sort of thing (usually for other 3rd party integrations such as qualtrics).
Abstracting all of it to a Data Element is... ehhhhhh... more often than not, probably overkill, in practice. But in general it is good practice to make use of DE's, just in cases. And again, sure, Adobe could bake that into a prefab DE, but again, question of coupling tools. Yeah they are both Adobe tools, but I'm pretty sure they aren't maintained by the same dev teams. But even if somehow they are, loose coupling almost always trumps all.
I definitely agree that scraping the AMCV_XXX cookie for the mid value is a bad idea. Today we can see that the cookie contains pipe delimited values, and we can see that "MCID" is the 4th value, and the actual mid (what is in the mid= param in the request, and what is returned by the above methods), is the 5th value. So we can easily parse this from the cookie
(btw, regex...really? Overkill. Just use your favorite method to grab the cookie value, and do var mid = "value".split('|');).
Except.. Adobe does not actually provide any official documentation or any kind of guarantee about the formatting of the cookie. So this works today, but there is no guarantee it will work tomorrow.