Some softwares, such as MySQL Community Edition, come with third-party-made packages, and the instructions are "Add us to your package manager's list of repositories; and pull Debian/Ubuntu packges from us.". The downsides of this are:
... for the system administrator, the necessity of a degree of trust that the third-party package repository will not sneak in bad versions of other packages. Package managers are not good at allowing system administrators to control and to limit what systems will pull from individual repositories.
... for the third party developers, the need to know how to build Debian/Ubuntu packages, and to keep up to date with all of the integration work that the Debian/Ubuntu maintainers would be doing for them, including all of the Debian/Ubuntu patches.
This highlights a problem with the quickstart guide that you got wrong. It does not make the user install systemd service scripts. It makes the user install van Smoorenburg rc scripts, complete with PID file nonsense, run levels, hand-rolled log management, and a lack of correct (or indeed any) LSB headers. This is two init systems behind the times for Ubuntu, which was upstart before it was systemd, and which hasn't been van Smoorenburg rc for over a decade now.
Ironically, the systemd service units are some of the very things that are added on by the Debian/Ubuntu maintainers that one loses by not going the Debian/Ubuntu packaging route:
Adding systemd service units to redis proper, in contrast, has been stalled for a while now:
As someone who maintains software that uses Redis heavily, I view 3.0 as somewhat recent and very usable for most. There hasn't been significant functional changes in Redis since 2.8 (the SCAN commands). Nothing significant in 3.0; the GEO* commands are the major feature in 3.2.
I still have plenty of customers on Redis 2.8.