Is this idea for a password manager secure? If so, why doesn't anybody use it?
One problem with this kind of solution where a predictable algorithm is used to generate a secret from a master password/phrase, is that if your master password is compromised directly (e.g. keylogger) or indirectly (e.g. an attacker with a password of yours generated through this system who can carry out a brute-force attack on it), the attacker has effectively compromised the security of all of your accounts, as they would be able to easily generate the passwords you use for all sites.
In short, this method provides little to no additional security over a regular password manager (possibly even reducing security, depending on implementation), and has several usability issues that make it impractical.
Security
Let's take your example of malware using a keylogger to get your master password and then compromising all the passwords in your password file. Your proposed scheme provides no additional protections against that attack: if your master password is stolen through a keylogger, then the attacker has all your passwords for all services. (No need to even steal a database here, just the master password.)
Another threat you mentioned was the developers of your password manager compromising your security by updating their password manager to steal your master password or decrypted password database. This threat is not mitigated by your scheme either, as the developers of the program you use to generate your password hashes could do the same. (I'm assuming you're not writing your own hashing tool. That seems nearly as inconvenient and error-prone as writing your own password manager.)
You also mentioned the privacy issues of cloud-based password managers knowing when you access your passwords. While this threat is mitigated by your proposed scheme, it can also be mitigated with traditional password managers by always keeping a copy of the password database synced to each local device and referencing that file when looking up passwords, or by simply storing your password database completely offline. KeePass, for example, supports both of these methods.
Finally, there is one additional threat this scheme opens you up to. It allows any site that you sign up for, or any attacker who obtains the password database for such a site, to make an unlimited number of offline brute force attempts against your master password. This can be mitigated by using a strong master password and a slow hashing algorithm, but it is still a problem worth considering. You could also mitigate it by including a pepper as part of your hashing algorithm, but then you lose the main benefit of your proposed scheme by requiring the user to access a file containing the pepper to obtain their passwords.
Usability
As for usability, as you noted this scheme does have the benefit of not requiring the user to keep track of a password database. However, there are a few usability issues I see with this scheme that I believe greatly outweigh this advantage.
The first is that if your password for a specific service is compromised (e.g. a site stored their passwords in plaintext and has their database stolen, or the password is stolen in-transit through a man in the middle attack), you have no easy way to change the password for that service without changing the passwords for all your other accounts as well (e.g. by changing the master password). You could add an additional parameter to the hash generator, such as an incrementing number, to allow passwords to be changed, but then you have to remember this number for every service, which is rather inconvenient.
Similarly, if for whatever reason your master password is compromised, this scheme makes changing that password rather difficult, as not only do you have to change your password on every site you have an account on, but you also have to remember every site you have an account on to make sure you don't miss any when changing your passwords - there's no convenient listing of all those sites as with a password manager.
Another usability issue which is a bit less obvious but, from my experience with password managers, I believe this scheme might run into, is that it's not always apparent what the "name" of each site you're visiting is. You might think you can just plug the domain name of each site into your hash algorithm and use that as the site name, but that's actually not always the case. As a simple example, consider this very site, Information Security Stack Exchange. Assuming you choose to use a password-based login for this site and not federated login through a third party like Google or Facebook, what do you use for the site name in your scheme? security.stackexchange.com? stackexchange.com? stackoverflow.com? All of those domains use the same login. And once you choose which name to use, you have to remember it. Other sites can make this even less obvious, such as, for example, gamepedia.com, which requires that you log in with your "Curse Community" account, which is shared between multiple sites made by that company.
And finally, possibly the most significant usability issue with this scheme, is sites with restrictive password requirements. What if one site requires that your password contain a special character, while another site requires that you only use alphanumeric characters? You could add options to your hashing scheme to accomodate these requirements, but now you have to memorize and remember the password requirements of each site whenever you want to sign in.
TL;DR
While your proposed method does solve some problems, it also creates others, and doesn't provide any additional security.
Security:
- N/A: Doesn't protect against malware
- N/A: Doesn't protect against malicious developers of password management software
- N/A: Doesn't provide any privacy protections that existing password managers cannot
- Con: Exposes master password to brute force attacks from malicious sites and hackers
Usability:
- Pro: Frees the user from having to manage a password database file
- Con: Changing site-specific passwords requires remembering additional site-specific information
- Con: Changing the master password is inconvenient
- Con: It's not always obvious what site name to use as the input for the hash function
- Con: Managing sites with restrictive password requirements is very difficult
What you're thinking of has been done quite a few times already.
Here's an example: http://plevyak.com/dpg.html
It's called a Deterministic Password Generator, meaning it creates passwords based on other information that you enter. Just like you said, using your master password, some other information, and the name of the site.