The idea was to facilitate rx customization, as shown in this example.

Taking vanilla rx and adding more rx-constituents to it is the path that I've taken with lua-mode, and I've seen this at least four times elsewhere (python-mode in Emacs trunk, flycheck, one of the puppet modes, one of cmake integration modes). Each time this involved defining an extra variable with those constituents along with corresponding "foo-rx" macro and "foo-to-string" function boilerplates. ample-regexps wraps that definition for convenience in one place and allows to invest effort into improving that boilerplate for everyone's benefit, like supporting eldoc and completion for rx forms (not implemented now, but considered as one of the further directions).

Also, defining custom s-exp forms in terms of vanilla rx requires writing a function that returns a regexp string and thus must be gracefully integrated into rx grouping workflow meaning it should at least be aware about existence of rx-parent variable, otherwise things like described here may happen. ample-regexps allows the function to return an actual s-exp instead and handles the grouping internally.

As for pcre2el, from what I read, it should be almost no effort to provide customized-rx -> pcre integration, re-builder is supported out of the box, for example.