I think we can all generally agree that enterprise software supporting Red Hat Enterprise Linux (RHEL) is a necessary prerequisite for selling into corporate datacentres.  Not only is it the predominant platform, but by paying for a RHEL subscription the customer prequalifies themselves as being prepared to pay for software - even open source software.

CentOS and Fedora as feeders to this system equally should not be ignored.   While clearly a much smaller percentage of the market,  this conversation also includes the SuSE Enterprise Linux/OpenSuSE ecosystems (although vendors don't seem to be specifically targeting this distro).  One may certainly say, with some merit, that Ubuntu underwrites more than 50% of the public cloud; however, it's not clear that Canonical has much presence in corporate datacentres nor uptake of LTS - hence focus upon proven monetisation around RPM.

If your application/stack is in RHEL then it has great visibility in the enterprise space.  This means your solution may become integral to a larger ecosystem.

Take Puppet Labs offering for example.  Puppet has a lot of incumbency, and perhaps sits in the most privilegedly attainable position in this discussion.  That is because Red Hat's own Release Engineering team takes responsibility for the RPM release cycle's around Puppet (the Open offering at least) across these RPM channels.  Not only does this give Puppet an easy pathway to get into company's and for developers and administrators to trivially deploy it and gain expertise, but Puppet is integral to many of Red Hat's premium cloud and orchestration tools (Satellite/Puppet/Foreman/Katello).  Red Hat actively promote Puppet in their sales and marketing; invite sales forces to exhibitions and events; and carry the branding on their products.

Clearly, we're not all as fortunate as Puppet Labs, but one can certainly steward their RPM packages through Red Hat's processes.  Another alternative is to offer RHEL/CentOS-compatible/supported packages from your own Yum repo.  This is very common and quite straightforward to implement and promote as a download/deployment option.

But here's the rub: although many company's do offer this; and even incorporate the package into an appliance (straightforward with kickstart and other imaging tools), they fail to do so properly: if you elect to isolate yourself from the distro by bundling your own Python, Ruby, Erlang, PostgreSQL, or whatever in /opt - you've really just offered a golden image/snapshot that offers none of the benefits the subscriber has paid for.  Any security patches, fixes, improvements to the native distro packages aren't visible in your application.

Not only that, if there is an issue with anything outside of your specific application code - I'm much more confident Red Hat's engineering staff have much greater expertise and incentive to triage, fix, and curate Python, Ruby, Erlang, or PostgreSQL issues than you do - and almost certainly will have a much more aggressive update schedule around them.  That is the reason we paid for the subscription in the first place.

Invariably these monolith RPM packages are the kitchen sink all in one deployment of a sophisticated, clustered application.  This doesn't lend itself to RPM updates to the new versions (upgrading backend database schemas for example) and you're substantially locked into this VM/version until you elect to start again on the latest incantation.  RPM offers a range of features for triggers, pre and post install etc which functionally can perform these tasks - but considerable engineer effort needs to be put into maintaining this to assure compatibility across versions over time - quite likely much more than the vendor is prepared to independently invest.

Whats more, the enterprise may well already have shared services and other existing infrastructure around RDBMS, message queue, web components baked into this package - but no way to integrate with these operational silos.

It is difficult to see this kind of package as anything other than trojanware.  Obviously, upselling is a critical part of any offering - whether to migrate you to the vendor SAAS platform, install a licence key to access premium functionality, or other form.  It's in everyone's interest to assure the financial viability of the vendor.  But it is easy to see how your appliance/RPM install cannot be migrated/upgraded to the premium service simply because of the monolithic packaging - at least without manual intervention and a fundamental appreciation of version changes and persistence within the application.

Somewhat related, why not also open the SRPM that generated the RPM.  Someone else just might generously package your system for other distro versions or architectures - or even improve your SPEC file - or even steward/sponsor/maintain it in a distro.  Of course, if you've lazily used fpm or such tool to auto-generate your RPM, then it most probably resembles the monolith above.

It may well be another conversation entirely about how to monetise an enterprise application within Red Hat's ecosystem - and it's only one distribution channel, but very visible and probably too important not to have a narrative around.