I think it’ll help Python add-ons greatly because (edit: most of the time) we don’t really care what keys are being hit, but what actions they translate to, so we can have the add-on reacting properly inside modal().
The work to be done seems to be exposing the functionality of defining modal keymaps to Python operators, because the built-in operators are already able to do that using an EnumProperty like this.
At the moment I have to use a hackish way, inside the register() function I add several disabled “wm.call_menu” keymaps hidden inside the “3D View Generic” input category, storing some data in their “properties.name” attribute. When my modal operator is invoked, I search for these entries and set up some simple event-handling inside modal() to detect when their key combinations are being pressed, and then call the function name that they store.
This is how I support customizable, persistent keymaps for modal actions in Bézier Mesh Shaper for 2.79 and 2.80+.
I use a JSON setup that loosely parallels the dictionary system you use for keymaps in MACHIN3tools, supported by a global object holds extra data for cross-referencing. If you adapted @RNavega’s approach to use a dummy-operator with some extra StringProperties for storing more data, and a global object that can pull your default modal configs from your keydict if a matching operator isn’t found, you’d end up with a decently robust workaround. Throw in a few ID fields, and you’d be able to support multiple modal keymaps per operator without needing excessive if...elif sequences, too.