For Wikipedia, I imagine they have interests in making the content most accessible on the maximum number of devices. Which means pages crafted to be lightweight and minimal Javascript. Yes, you could do that all in one page, at the altar of developer velocity, but I think the strict isolation is user forward.

A quick test from Firefox dev tools for initial page load: - https://en.m.wikipedia.org/wiki/Phonon 1.04MB, Finish 619 ms - https://en.wikipedia.org/wiki/Phonon 1.94MB, Finish 1500 ms

I'd guess its essier to manage caching.

Wikipedia launched that in July 2013 in response to rising web traffic and the existing site not working well on mobile browsers. That was preceded by Wapedia, an independent site that started in 2004 to provide a reformatting proxy for mobile use: https://en.wikipedia.org/wiki/Wapedia

The basic answer is that early on the tooling wasn't there to support very difference devices from the same HTML. You could try tricks to detect mobile devices and serve different content. But it was much easier just to let people decide which they wanted.

I haven't kept up, but I know the tooling keeps improving, so I expect that few people today are creating mobile-specific URLs, and that the existing ones will go away in the long run.

IIRC it dates to before we had things like media-query in CSS or other good ways to adapt the page load to the device.

Wikipedia's mobile site was originally running completely separate software (https://www.mediawiki.org/wiki/Wikimedia_Mobile_engineering/...).

My guess is that it was easier to set up that way at the time, and then the configuration was kept when a mobile version was integrated into MediaWiki itself.

There are plans to merge the domains (https://phabricator.wikimedia.org/T214998), although they are vague and stalled.