But it's the same in any case, right? It's always, "if an attacker gets your <x>, they have all of your passwords."

The question is: are they any more likely to gain a seed that I keep only in my head vs. a list of passwords in an encrypted datastore?

They're still different, the two schemes. In the case of a traditional password manager, an attacker would need to get your master password and the password datastore. In the case of datastores stored locally, rather than online, that's still two separate steps.

In the case of your idea, once an attacker knows the seed, they have everything. Furthermore, if there's some weakness in the algorithm you use to generate passwords from the seed, then some site which has one of your deterministically-generated passwords could potentially breach the weak algorithm to reverse the process and obtain your seed, along with all your other passwords.

Lastly, with a traditional password manager, you can change the master password at any time. Would you be able to change your seed when needed, or would you need to regenerate your passwords for EVERY site, if you need change the seed because it's been compromised?

Except you won't keep it only in your head: you'll be typing it into a computer at some point. Really, in either case, you should also be using token-based 2FA as well.

OK, so a surreptitious keylogger still defeats this config. I'm OK with that. My entire life presumes trust from my keyboard to my computer.

I mean, if that were my main concerns, I'd have to rethink most of the bedrock security precautions I take, like passphrases for private SSH keys, etc.

At the end of the day: I understand the risks and view them as absolutely acceptable in order to gain reasonable portability in a password manager.

In the case of a password manager they would need the database and the master password. In the deterministic case they only need the seed.