I'm confused... isn't Devuan exactly this?
What would actually be useful would be a generic OpenRC wrapper that would ingest those service files and provide traditional start/stop interface for them.
* https://jdebp.uk/Softwares/nosh/guide/commands/convert-syste...
* https://jdebp.uk/Softwares/nosh/guide/converting-systemd-uni...
* https://jdebp.uk/Softwares/nosh/debian-binary-packages.html
...and then keep up with behavioral changes that the Systemd Project people introduce and load-bearing bugs that services end up relying on for lifecycle management.
OpenRC service files are easy to write, and their schema is far far simpler than that of Unit files. [0] It's really not worth the effort to write and maintain an converter, if for no other reason than you need to understand the semantics of both systems' service files to double-check the results of the converter.
Eventually, the pain of supporting everything became too much and debian did go with "my way or the highway", which I supported at the time and still do. I have no idea how that could be "objectively worse", it's very obviously a tradeoff to me. If your packages have to work on any init system, they can not benefit from any particular init system's features and have to work with the lowest common denominator. Every service has to hack around the lack of working state management with pidfile hacks and such.
In my opinion, it's better for a distro to pick any single init system than to try to support them all by limiting all packages to SysV style init scripts. Yes, user choice is important, but that can and does happen via distro choice. Alpine or Devuan are right there if you need them. Linux is fragmented enough, we don't need every distro to be a microcosm of the fractured overall Linux landscape.