Putting keys in a text file doesn't fit the narrative of a generally-careful user forgetting about side effects and metadata.

It's important to know where your keys are, but it's also important to not store your keys in certain ways that are easily overlooked.

A lesson of "don't put secret keys inside the web root" is also useful.

But a lesson of "know where your keys are and secure them" is a bit too short-sighted. You don't just want them to be secure right now, you want the mechanisms keeping them secure to be mistake-resistant.

Don't put them in the code, even if you promise to be super careful.

Is there a general algorithm that can tell you all possible threats against your secret keys?

My approach to security, when discussing things with our engineers:

1. Make a list of everything that absolutely positively cannot live without this data/access/permissions/etc.

2. Put the data somewhere where absolutely nothing whatsoever can ever read it (except root).

3. Figure out what one single change will resolve #2 so that the things in #1 can happen without any other things gaining access.

If you don't do #1, you don't understand your requirements/applications. If you don't do #2, then your data is probably vulnerable through some other mechanism. If you can't do #3 then you probably need to change something else (e.g. stop running all processes as the same user, stop running all services on the same box, stop trusting users, set up more granular sudoers rules, etc).

What I find is that when you come up with an idea for #3, and then come up with a list of side effects, you can actually find a lot of the kinds of issues I mentioned above, for example where the public website CMS (as 'daemon') and the accounting backend (as 'daemon') both have access to the same resources, and thus someone gaining access to the CMS can get the accounting DB user/pass and get access to your transaction records, user database, etc.

No, there are an infinity of things that shouldn't have access to your secret keys. So you have to take a default deny approach, and ensure that only things that positively should have access to your secret keys do.