If there is an on-prem option, the release, the update/migration, the installation environment, and the documentation on deployment should be carefully crafted. All of these not only require more effort, but also require people to keep in mind not to stomp on things. And even worse, they have to search for potential problems with their imagination because they don't have access to the data with edge cases they're dealing with. If people are not careful, it's very easy to seriously screw things and lost some customers forever. On top of that, if fixes are required, the team usually needs to fix multiple versions over and over, of which the codebase might have drastically changed. The teams are usually less and less "brave" as time goes by.

For most SaaS without on-prem options, people can just focus on the functionalities and deploy many, many times a day. For non-critical issues, people don't need to worry about them, just debug what's going on and respond fast, and the issues are very likely fixed in hours. Plus they can use components like Kafka, Elastic Search, or even other SaaS as needed, without having to choose between re-invent things or ask everybody to install a zoo of components in their on-prem solutions.

That's one of the key reasons why web application is so popular nowadays compared to what we've done in the 90s desktop applications. Because it enables the "move fast and break things" mentality because more things are fixable in web applications. On-prem is like 90s desktop applications in disguise. Just try to imagine how horrifying if someone breaks the upgrade functionality. Or if one needs to fix a bug in Windows 10, they also need to fix it from like Windows Vista to Windows 10, where the codebases are drastically different.

In conclusion, on-prem sounds applaudable to the audiences on HN, but the reality is it doesn't work well for most for-profit businesses.