Let me explain to this viewpoint in more detail - I have a rather clear picture for the scenario where "one easy-to-remember password for large number of sites" is the proper action to take.
Thre are a lot of sites that want me to have "an account" so that I can do action X. That includes nearly all my passwords in my password manager. For every account that I want to be secure (say, my email) there are ten accounts that I don't want to have. If I want to do X, I don't want to have an account. "Having an account" is a cost - I have to remember the account's data (even the bit 'do I have an account on fancysite.com?' is a cost). If I have to have an account, I have no need for the account to be mine and mine only. If I have to have an account for me specifically, I have no need for it to be protected from others; but I do need to remember it easily - to avoid the inconvenience of creating a new account.
The site owners often make very different policies, for reasons that benefit them - but they are often opposite to the user needs. All the security problems related to the accounts are the fault of those people who required "an account" in the first place - the Adobe breach is a good example, none of those accounts shouldn't have existed in the first place; none of those people should have been asked their emails; none of those people should have been asked to choose a password. The stricter password requirements Adobe would have made - the worse that would harm the actually important accounts. The sole fact of Adobe asking large number of people for their email address and asking to 'choose a password' - that's a hostile attack that harms mass security on the internet (as the consequences of that breach); we should actively subvert such policies. If a site asks you for an identity more than actually needed (i.e., if they need to ship stuff then they need an address) or asks you for more authentification stuff (choosing passwords, security questions, etc) than you need, then that's [security-wise] hostile to you; if you like that site you can suffer through that but you should do the absolute minimum that fits their policies.
Ignoring client-side tools that hide the complexity, let's list some reasonable possibilities for user authentification for the actual accounts (where I explicitly don't care about others getting access to that account but I care about protecting other accounts) sorting them by ease of use (i.e., how I would like to 'log in' to the site), more preferred options first.
1. No identification or authentification at all. For many scenarios that's the optimum that we'd like to have, but it's prohibited by the site operators, so we're forced to go 'downwards'. #1 on ease of use; #1 on security (no risk to be a proxy for attacks on important accounts), #1 on privacy.
2. Arbitrary identification with no authentification - i.e., I pick a name/tag, and that gets used as a semi-unique handle. This allows semi-personalized communication (i.e., distinguish multiple commenters) or some persistence of data. For some scenarios, e.g., most of online commenting this is the optimal point. On some sites I'd want to 'build a reputation' by having a handle that's unique to me; but on most of them the hassle of remembering an account name is larger than this benefit, so I'd prefer to post with an unauthentificated pseudonym. This again is often prohibited, so we're forced to go 'downwards' or to not use such sites - all the next options are just drawbacks that users choose to take in order to gain access.
3. Authentification without identification - publicly available login data, such as the BugMeNot system. This attempts to go to the goal (#1) by sharing data, but again, those accounts often get prohibited by the operators, forcing us to worse measures further down the list.
4. Username/password - optimizing for ease of remembering. That would ideally be a single username and a single password for everything - i.e., the best password was no password (#3), the next best password is a single, simple, short password such as "password". Again, that doesn't work because [some] site owners have expressly prohibited it, so the next best option is a single, simple, semi-short password with a number of special characters such as "Tr0ub4dor&3" - so that it could actually be single and fit policies of a majority of sites. This approach sucks security-wise, as you note - however, the major security flaw for this is actually not the weakness of passwords, but the weakness of usernames - since the authentification doesn't matter for those sites, but this approach leaks and connects identities, which is bad on principle. However, without moving to things such as password managers which wouldn't work when you sit down on a random untrusted computer, I'm not aware of any better options that don't have this flaw; if there are multiple usernames/passwords, then something needs to remember them; and that something itself needs to be accessible with very easy-to-remember (and most likely completely insecure) settings.
5. "Classic" system of not-the-same IDs (to prevent linking them) and secure, periodically changed passwords that are unique for every site - that's not an option. For the large class of unimportant accounts, the total value of the account is less than the cost of that effort. The only way around this is by client-side systems such as password managers that can automate account creation and maintenance - so that while the "hidden" account is secure, the whole process from the user point of view behaves as one of the previous options. That is also a threat, since then (due to natural habits) people use those tools also for the important accounts, and that opens another source of vulnerabilities for them; in an ideal world I'd choose to have no authentification for the vast majority of places, and I'd be able to remember proper passwords (+2FA) for the couple things that actually matter.
"Too much trouble" is the whole point. The value of security for such accounts is approximately zero - if some solution doubles (or creates?) security but requires an extra click or two, then it's a bad tradeoff that simply shouldn't be done.
Why should people spend any effort at all to secure things that shouldn't be secured in the first place? Why should anyone remember a single bit of info or download an app or spend an extra keypress to protect an account that's already public in intent; but "private" because someone else wanted it to be private?
There are security problems if you use your 'throwaway' password for your primary email (as some of the people on Adobe list have done), but that's not the fault of the throwaway password, but in throwing away the keys to something valuable. That throwaway password should be something that's not a secret, as an equivalent to no password.
It should not even attempt to be protected - it's something that you tell your friends/colleagues openly (so that they'd not have to create their own accounts there, it's quicker to login with yours), post it publicly on the internet (again, bugmenot.com as an example), don't bother to change it years after some site has leaked it, etc. The password as such exists only because someone forces you to some tradeoff of "more security/less usability" - the only reason that the password is not, say, a 0-length string is that you're forced to do so, but there's no reason at all to go any further than the minimum.
For the majority of accounts that I have, the most appropriate level of authentification is not "a reasonable level", not "a minimum", but exactly zero.
I think new models and progress will have to be based on looking at the technologies available, such as cryptography and web protocols, and figuring out what are the best and most convenient systems you can assemble for various levels of security. For instance, a site can track your visits with a cookie, without your creating an account, as long as you use the same browser and the cookie doesn't expire. Cookies seem like almost enough for a lot of scenarios, except that you can't (currently) transfer them to a different browser and there's no standard way to distinguish the person that owns a cookie if multiple people use the same browser.
The value of security for such accounts is approximately zero
If I'm following your logic correctly, you might as well not go to the extra expense of vaccinating your kids, because the anti-vaxxers have already broken down herd immunity.
Thre are a lot of sites that want me to have "an account" so that I can do action X. That includes nearly all my passwords in my password manager. For every account that I want to be secure (say, my email) there are ten accounts that I don't want to have. If I want to do X, I don't want to have an account. "Having an account" is a cost - I have to remember the account's data (even the bit 'do I have an account on fancysite.com?' is a cost). If I have to have an account, I have no need for the account to be mine and mine only. If I have to have an account for me specifically, I have no need for it to be protected from others; but I do need to remember it easily - to avoid the inconvenience of creating a new account.
The site owners often make very different policies, for reasons that benefit them - but they are often opposite to the user needs. All the security problems related to the accounts are the fault of those people who required "an account" in the first place - the Adobe breach is a good example, none of those accounts shouldn't have existed in the first place; none of those people should have been asked their emails; none of those people should have been asked to choose a password. The stricter password requirements Adobe would have made - the worse that would harm the actually important accounts. The sole fact of Adobe asking large number of people for their email address and asking to 'choose a password' - that's a hostile attack that harms mass security on the internet (as the consequences of that breach); we should actively subvert such policies. If a site asks you for an identity more than actually needed (i.e., if they need to ship stuff then they need an address) or asks you for more authentification stuff (choosing passwords, security questions, etc) than you need, then that's [security-wise] hostile to you; if you like that site you can suffer through that but you should do the absolute minimum that fits their policies.
Ignoring client-side tools that hide the complexity, let's list some reasonable possibilities for user authentification for the actual accounts (where I explicitly don't care about others getting access to that account but I care about protecting other accounts) sorting them by ease of use (i.e., how I would like to 'log in' to the site), more preferred options first.
1. No identification or authentification at all. For many scenarios that's the optimum that we'd like to have, but it's prohibited by the site operators, so we're forced to go 'downwards'. #1 on ease of use; #1 on security (no risk to be a proxy for attacks on important accounts), #1 on privacy.
2. Arbitrary identification with no authentification - i.e., I pick a name/tag, and that gets used as a semi-unique handle. This allows semi-personalized communication (i.e., distinguish multiple commenters) or some persistence of data. For some scenarios, e.g., most of online commenting this is the optimal point. On some sites I'd want to 'build a reputation' by having a handle that's unique to me; but on most of them the hassle of remembering an account name is larger than this benefit, so I'd prefer to post with an unauthentificated pseudonym. This again is often prohibited, so we're forced to go 'downwards' or to not use such sites - all the next options are just drawbacks that users choose to take in order to gain access.
3. Authentification without identification - publicly available login data, such as the BugMeNot system. This attempts to go to the goal (#1) by sharing data, but again, those accounts often get prohibited by the operators, forcing us to worse measures further down the list.
4. Username/password - optimizing for ease of remembering. That would ideally be a single username and a single password for everything - i.e., the best password was no password (#3), the next best password is a single, simple, short password such as "password". Again, that doesn't work because [some] site owners have expressly prohibited it, so the next best option is a single, simple, semi-short password with a number of special characters such as "Tr0ub4dor&3" - so that it could actually be single and fit policies of a majority of sites. This approach sucks security-wise, as you note - however, the major security flaw for this is actually not the weakness of passwords, but the weakness of usernames - since the authentification doesn't matter for those sites, but this approach leaks and connects identities, which is bad on principle. However, without moving to things such as password managers which wouldn't work when you sit down on a random untrusted computer, I'm not aware of any better options that don't have this flaw; if there are multiple usernames/passwords, then something needs to remember them; and that something itself needs to be accessible with very easy-to-remember (and most likely completely insecure) settings.
5. "Classic" system of not-the-same IDs (to prevent linking them) and secure, periodically changed passwords that are unique for every site - that's not an option. For the large class of unimportant accounts, the total value of the account is less than the cost of that effort. The only way around this is by client-side systems such as password managers that can automate account creation and maintenance - so that while the "hidden" account is secure, the whole process from the user point of view behaves as one of the previous options. That is also a threat, since then (due to natural habits) people use those tools also for the important accounts, and that opens another source of vulnerabilities for them; in an ideal world I'd choose to have no authentification for the vast majority of places, and I'd be able to remember proper passwords (+2FA) for the couple things that actually matter.