The signature of the generated stub for bpy.data.objects in my module looks like this:
objects: typing.Union[typing.Sequence[Object], typing.Mapping[str, Object], bpy_prop_collection] = ...
I know it looks damn ugly, but it does what it’s supposed to do 
I agree that it’d be ideal to take a hybrid approach from both of the methods. I believe it wouldn’t be that difficult to change my project to utilise information extracted using the interpreter, if needed.
I created it in a way to ensure it’s easy to extend its parser. When you run it it will report cases where it fails to determine a correct type from the docstring. And the part that handles it is designed in a modular way and has test suites which runs pretty fast.
As such, the cases where it doesn’t handle right, we can either submit a patch to make the relevant docstring more regular (which I did recently) or fork my project to extend the parser and submit a PR.
I already setup CI pipelines that publish snapshots and release builds to PyPI for Blender and UPBGE. So I hope it’d be able to keep up with the Blender/UPBGE development to provide the latest and fairly accurate API stubs for them.