In this respect, it looks like arguments against packaging Mapbox GL module of QtLocation are not linked anymore to the license nor inclusion of third-party code. Instead, it is mainly related to the size of it, right?
When using Qt, I would expect that all its parts (or open-source parts) are available on the platforms that package it. So, when I want to run a code that is calling Mapbox GL plugin, it should be possible if QtLocation >= 5.9 is packaged. Took some time to dig out why its not there on Debian-based distros and it seems now that the reason which holds is just a size, not license. I don't think it is a valid point to drop a part of it just due to the size. In this respect, it looks like a bug in packaging.
As for finding dedicated maintainer - I don't think its necessary, as it is not necessary to find dedicated maintainer to
https://github.com/qt/qtlocation/tree/5.12/src/plugins/geoservices/esri plugin, for example. QtLocation is released after corresponding tests and should have testing done as a whole as well. It looks to me that splitting a package that was developed as a unit and then finding a way to glue it back together (splitting qmapboxgl out of qtlocation and gluing it then back) is making extra work for not much gain. But I am not in packaging business - in writing software business instead - and can provide my 2c only from outside.
Note that situation with Pure Maps is somewhat different and I may converge to using QtLocation plugin system later as well to avoid keeping my QML bindings up-to-date. But I think covering full functionality of QtLocation is an expectation of the users from distribution.