Also, it talks about salting, but it's NOT a salt, or at least it's a horrible salt. A true salt should not be reused at all, it should be unique to each password hash. Generally you see something like '<storedhash> = salt + hash(salt + password)' so you can recover the salt automatically.
A global salt for all your stores passwords at least prevents generic rainbow tables from being used against a stolen password database. Salts per password prevents the same password from having the same hash result in your database.
There's really no reason to ever use a global salt, it's not like it's hard to generate a random one for each user. If you're already putting in the effort to use salts, might as well go all the way instead of saying "well it's better than nothing ¯\_(ツ)_/¯" (I'm not directing this at you in particular, just at anyone who intentionally takes half-measures when it comes to security)
Last pass used both: a global salt and a per-password salt. The idea was that the global salt isn't stored in the database so if the attacker doesn't have access to the application server, they cant find what that salt is at all.
Not sure where the line is drawn, but it's definitely inclusive of the more secure option when it can be implemented in <10 LoCs of code simple enough 99% of the professional dev community can write it.
Even worse, using an actual password hashing lib, i.e. golang.org/x/crypto/bcrypt, is usually going to take care of it for you. 2 lines of code, 1 to make the hash when the password changes, 1 to check if the password matches the hash, and you are done!(as the library already generates and includes random salts in the hash for you)
1. The password storage section where it gives MD5 as an option. MD5 should never be an option, not even in a simple testing / prototype application.
2. It actually calls base64 encoding encryption / decryption. This is really dangerous and outright wrong.
So if you ignore security related sections this guide overall seems good.