Some implementers reuse the same salt for all passwords. It's not the worst thing ever, but it does make it substantially easier to crack than if everything has its own salt.

It's because layering doesn't really gain you anything so it only has downsides. It's important to differentiate encryption and hashing from here on since the dangers are different.

With hashing, layering different hashing algorithms can lead to increased collision chance and if done wrong a reduced entropy (for instance hashing a 256 bit hash with a 16 bit hashing algorithm). Done correctly it's probably fine and in fact rehashing a hash with the same algorithm is standard practice, but care should be taken.

With encryption things get much worse. When layering encryption algorithms a flaw in one can severely compromise them all. Presumably you're using the same secret across them all. If the attacker has a known piece of input or can potentially control the input a variety of potential attack vectors open up. If there's a flaw in one of the algorithms used that can make the process of extracting the encryption key much easier. Often times the key is more valuable than any single piece of input because keys are often shared across many encrypted files or data streams.

The rest of that sentence is important. Hashing passwords is the minimum practice, not best practice. You should always be at least hashing passwords. Best practice would be salting and peppering them as well as picking a strong hashing function with as high a number of iterations as you can support. You would then pair that with 2FA (not SMS based), and a minimum password length of 16 with no maximum length.