Alright, what do you propose? As I said, dealing with keyfiles is HARD for the lay-user.
If the issue is "they have to transport them to use the crypto on systems other than their own": We should not be teaching lay-users (or non-lay-users) to enter passphrases or use private keys on untrusted systems.
For using multiple trusted systems, having the client software support multiple keypairs (like OpenSSH) or providing an easy way read the key off removable media (like an encrypted thumb drive) are great.
E.g. password 1: "the quick brown fox jumps over the lazy dog"
Password 2: "jack be nimble jack be sick"
Final result, used to derive a keyfile: "the quick brown fox jumps over the lazy dogjack be nimble jack be sick"
Notice how "quick" was switched with "sick" in the last word. Now there's no pattern that can be easily cracked. If we force a user to explicitly do something like that, then this can still work.
That example was chosen intentionally to be weak. It shows that even with two relatively weak passphrases, the result is still somewhat strong. If we add extra requirements on top of that, such as forcing the user to use numbers and capitalizations, then the result should be sufficiently unique.
Passphrases also don't protect against keyloggers, which is a downside of this approach.
Anyone trying to attack the system will just program their cracker to be more likely to try concatenating words together awkwardly in the password somewhere.
By forcing the user to choose two passphrases which are then concatenated, the result is one gigantic passphrase that a cracker can't easily crack, yet is easy for humans to remember. It seems like this solves the problem of rainbow tables.
A keylogger could still break this system. But if an adversary has planted a keylogger, they could've simply stolen your keyfile.