First, alternatives is from debian and will not work in redhat, freebsd or many other systems. Second, the standard recommendation is to use /usr/bin for vendor packages, /opt for third party packages, /usr/local/bin for local executables and set the path for user executables.
alternatives is intended where you can have multiple packages provide the same functionality, for example there are at least three mailx packages, two awk packages and multiple java packages available in debian.
Now to the meat of the matter: why do the tutorials use alternatives like you show? Because alternatives is used closely with debian packaging this allows a thirdparty package to mostly act like a vendor package. Should you use alternatives instead of install? Absolutely not, alternatives does not set permissions.
One of the core ideas in unix is that everything is a file. (This is not strictly true any more, if it ever was but it as a design goal shaped many things.) now there are three things you can do with a file that are associated with permissions. They are read, write and execute. When reading or writing there are two ways to specify a file to open. They are absolute path (the path relative to the root directory) or relative path (the path relative to the current directory). Executing is a little more complicated in that there are three ways to specify the file to be executed. They are absolute path, bare filename and relative path. The absolute path is the same as above. the relative path is similar to above but is only used if explicitly specified (the name includes a slash) or the path includes a relative path. The path is specified per process in the PATH environment variable (which is inherited from the parent process during a fork). The path is a list of directories to look in to find an executable when the executable is specified without a slash in the name. To simplify administration (and speed locating of executables) the executables are collected into a small number of directories. Most executables are in either /bin, /usr/bin, or /usr/local/bin with special purpose executables placed in /sbin, /usr/sbin, /usr/local/sbin and /usr/games. Some users will have additional binaries placed in other locations for their personal use. I like to place mine in ~/.bin but ~/bin is also common and other directories are sometimes used as fits the user.
When placing executables to be shared each user can tell other users where the binary is or put it in a common location. When putting executables in a common location you can either copy the file and set its permissions by hand or use install which will take care of the details in a simpler fashion. Sometimes you install complicated third party packages and don't want them cluttering up the main parts of the filesystem with all the related files (libraries, etc) and put them in /opt/package or /opt/vendor/package. You could add the relevant directory to the path, or place a wrapper script or symbolic link in a standard directory. alternatives places a symbolic link and a database entry so that when you have more than one program available that has the same basic functionality and the same executable name, the right one is used.