Hi @cppmm,
I stopped working on Certbot before this decision was implemented, but I'm somewhat familiar with it.
(1) The Certbot project doesn't try to stop anyone from maintaining official OS packages of Certbot, and some operating systems do, and some people use them. I recently used such a package myself as part of a test version of a project. If you do use an OS that has such a version, or if you can persuade your OS developer to do it, that's great and you should definitely feel free to use this installation method. I think it's possible that more OSes will do this (again?) if a lot of users choose to ask for it. (I personally have dozens of things installed from OS packages on my laptop that are also available as snaps; it's not really that impossible for software to be distributed in both ways, even where the main developers are supporting or recommending the snap method.)
(2) The Certbot developers found that the typical OS package was very out-of-date by the standards of the Certbot project, especially in distributions that greatly prioritize stability and require an explicit justification (such as an exploitable vulnerability in an old package version) to update a package version after a code freeze or after a distro release.
This was often annoying to Certbot users and developers, because at least as of a couple of years ago, Certbot was changing relatively quickly (maybe compared to more mature software whose users might be less annoyed by having an older version in their OS). In some cases, people didn't have access to features that were relatively important to them, even though the OS developers didn't consider it to be a security vulnerability. Certbot isn't the only package that's run into this controversy with distributions; I remember witnessing an especially bitter fight about Chromium in this regard (where the Chromium developers actively disagreed with the idea that they should have to explain which fixes were RCE vulnerability fixes, and considered that all releases were in some way essential security releases).
(3) I know snapd is pretty controversial, and some people have no other reason to have it installed on their servers at all. It would be nice to have a widely available, lighter-weight, portable, and perhaps more decentralized alternative. Basically, it's a single target that the Certbot developers can aim at and that's typically available to most users and that guarantees that those users will have access to up-to-date Certbot releases.
On most OSes you can also relatively easily install Certbot in a Python virtual environment. (I've also done this myself for some projects, and it's worked reasonably well.) The Certbot project has documented how to do this as an option aimed at developers, but not suggested it to users in general, perhaps because most Certbot users aren't really very familiar with pip and virtualenv (or their consequences in terms of how to update things or how to invoke commands inside the environment). Indeed, if you do install this way, I think you'll typically need to create your own scheduled task (like a cronjob or systemd timer task) to run certbot renew, as no Certbot-provided version would be able to guess how to invoke Certbot in your particular Python virtualenv.
For people who are relatively familiar with Python and the Python ecosystem, I think this can be a reasonable and appropriate choice. It doesn't take particularly long, and it's not particularly complicated if you know what a virtualenv is and how to run software inside of one.
I think I've seen one case recently where Certbot did encounter a dependency problem when installing this way, but I think the Certbot and/or pip developers would consider this a bug and would be willing to try to get it fixed.
Edit: We just had this thread right now where the official OS package version was Certbot 0.40. That's a release from November 2019, which for some software wouldn't be a big deal, but which for Certbot feels pretty old and likely missing a lot of new functionality. (But it doesn't have an RCE or privilege escalation bug, so I guess the distribution doesn't consider it, as a matter of policy, worth making changes that conceivably might not be 100% backwards-compatible.)