When building a website, you (usually) know exactly what server it will run on. Or, at the very least, you will set up the server(s) afterwards to the exact requirements of your code.
For example, if you write an API using PHP8, you will assume that the server running the code will have ... well, PHP8, and probably a good caching infrastructure. In the world of CMS plugins, you can assume exactly none of that.
The only assumptions you can make are the requirements of the CMS itself. In the case of WordPress we can safely assume that we'll have the following things:
The list of assumptions is not PHP7. It's not even PHP5! It's simply PHP. Maybe the plugin is running on WP5+, maybe it's running on WP2.7 or lower. Maybe it's MySQL, maybe MariaDB, maybe something else.
That doesn't mean that our plugin needs to support every version under the sun, but it does mean that it must be prepared to handle less-than-ideal environments gracefully.
In 99% of the cases, we don't actually care about the underlying database system. However, we care about the WordPress and PHP versions in 100% of the cases!
Of course, WordPress has supported forever the Requires at least plugin header line that only lets you to install or update a plugin from the public repository if your WP version is higher than the minimum specified. Since August 2017, there also exists a Requires PHP line that does the same thing for the PHP version.
All of this doesn't apply to premium plugins however. Also, it doesn't stop people from manually uploading a plugin's files either through FTP/SFTP or via the admin GUI. One can also argue that with the release of the PHP fatal error protection feature in WP5.2, such checks don't matter because the plugin will simply fail to activate so the website will keep working.
While these are valid points, they don't fulfill all the requirements:
Degrade gracefully, i.e. do not throw any errors and let the user know about the problem
What if someone actually tries to install your plugin on WP5.1?
Getting this right is not complicated, but it definitely counts as a boring, repetitive task when starting a new plugin project. The purpose of this module, therefore, is to run on as many PHP+WP combinations as possible and graciously stop the whole plugin from running if the minimum requirements are not fulfilled.
In an ideal world, the Bootstrapper module would run on all PHP versions back to the early releases of 1995. In the real world, however, we need to draw a line somewhere. In our case, that line was PHP5.3, the first one to support namespaces. According to the official WP stats, that forsakes about 0.6% of users as of April 2021.