I was trying to approximate the .launch extension that we had in ROS 1 (which would have contained XML). When people wanted to compose a launch file out of XML files they would use .xml for the parts, indicating that the .launch files were actually viable entry points for launching.
The .launch.py was a way to imply it was both an entry point and clue editors to the markup of the contents. It is currently completely optional and is only considered with tab-completion.
I had imagined that people who wanted to unit test their python code used in launch files would place testable code in .py files and have a single .launch.py that uses the code in the .py files to return the launch description. I have also imagined that if you wanted to do an integration test where you actually instantiate the launch file for introspection or launching you’d do that with the launch API (which handles imports for you).
For general purpose composition (a launch file including another launch file) that can (and probably should be) done with the IncludeLaunchDescription action in launch.
To alleviate other use cases we could expose the importlib logic used in launch itself to handle the .launch.py suffix.
That all being said, while I prefer the aesthetics of .launch.py, I would be fine with canonicalizing _launch.py or something else and I’m interested in hearing from others on the topic.