First of all, you should not encrypt passwords. Encryption is reversible.
Instead, you should hash the passwords. A hash is kinda like one-way encryption.
When the user signs in, instead of decrypting, you
encrypt hash the password they provided, and see if it matches the hash that is already stored in the database. If it's the same password (and salt), then the resulting hash will be consistent and you can let them in.
When hashing passwords you have to consider a few things:
It's important to use salt to prevent side-channel attacks in relation to duplicate detection.
You should use a well-vetted routine.
You should use a high enough Work factor so it is expensive to brute force.
I've explained all the considerations here: Why is MD5 considered a vulnerable algorithm?.
In summary, you should use BCrypt. (which has had more time to be vetted than Argon2)
Run a quick SHA-256 on the password before feeding it to BCrypt. (to prevent truncation)
The BCrypt Work Factor should take 50-500ms on your target machine.
Limit login attempts to prevent Online Brute Force as well as DoS via hash computations.
BCrypt already has Salt, but it's best to also include some Pepper (~72 bits of entropy) which is a quick sort of extra password added to the user's password. The Pepper is the same for all users, but is unique to your application. It is stored either in your source code, or better yet, in a separate text file, but never stored in an SQL database.
Include reasonable Password Strength Requirements in your application, because no amount of hashing will protect a weak
Would an unencrypted password database in a system be considered a vulnerability? (think yes)
If you don't hash or encrypt, it's a vulnerability for sure.
Would an unsalted hashed password database in a system be considered a vulnerability? (unsure)
Yes, primarily because of rainbow tables. However the bigger concern would be how strong of a hash function you are using. Most of the good algorithms already have salt, so if you don't have salt, there's a good chance you're using a weak algorithm.
Would a salted and hashed password database be considered a vulnerability? (tend to think no)
You're right, this is OK. It's common to store both Salt and Hash in an SQL Database, but it's best to also include Pepper which is kept outside of the SQL database.
And would an encrypted password database but with a same "secret" key be considered a vulnerability?
Yes. Reversibly encrypting passwords is bad. If the key is stolen, the passwords are easily retrieved without brute force. Hashing solves this problem.