Thank you for opening the issue and for a very well considered report! For reference, a similar issue is encountered with the gitHubKeys template function (#2253) and a "no network mode" has also been discussed previously (#2354).

tl;dr summary: caching is hard and there might already be a work-around.

A couple of questions/possible solutions:

1. Is there a particular reason why a GitHub token is not an option for you?
2. chezmoi apply takes an optional list of targets to update. The default is all targets, but you can run chezmoi apply ~/path/to/tweak to just update a single file or directory. This is both significantly faster than running chezmoi apply. chezmoi goes to some effort to do the minimum work required to get the answer you want (it's not perfect but not too bad). That said, with the current architecture chezmoi always needs to evaluate externals, so it won't actually help with the rate limiting.
3. Another solution is to move the call to gitHubLatestRelease to your config file template. Roughly you speaking you put data.program.version = {{ gitHubLatestRelease "repo/program" | quote }} in your config file template and then use {{ .program.version }} in your .chezmoiexternal file. This means that gitHubLatestRelease only gets called when you run chezmoi init (solving the rate limiting problem) and the change to a new version only occurs when you want (which can be a bit more secure, as you don't blindly import the latest version).

Would any of these be an option for you?

1. It's not that it's impossible to use in my case. But it just felt like the wrong solution to the problem, as it clearly makes no sense to evaluate gitHubLatestRelease in this particular situation in .chezmoiexternal. So I created this issue to see what may come of it.
2. That would be viable for me, as the offending .chezmoiexternal is off in its own directory. But from your comment, I understand that it's not actually viable in the current version?
3. Here I'm kind of confused. From the docs it sounds like init is used to create a new source root and config file. I already have a source root and a config file, and would not want to overwrite them. If init can be made to act in a way like "evaluate a config template and merge it with existing config", then it's not clear from the documentation.

And on the topic of using sneaky template evaluation methods to solve this problem: I already had an idea that I could use scripts and cache directory to keep my own timestamp of last run, and then gate the offending .chezmoiexternal entry with an if that compares it with output "date" "+%s". I may still end up doing it this way (for now, I just keep the version pinned).

But again, it feels like an ugly hack for something that should be relatively easy to provide by chezmoi itself. Especially since I expect my case to not really be rare. People probably use gitHub* functions in .chezmoiexternal, and those externals probably have reasonable refresh periods, that make unnecessary github requests.

3. Here I'm kind of confused. From the docs it sounds like init is used to create a new source root and config file. I already have a source root and a config file, and would not want to overwrite them. If init can be made to act in a way like "evaluate a config template and merge it with existing config", then it's not clear from the documentation.

@mkalinski Running chezmoi init for this purpose will not overwrite your source state. It will execute your config template and overwrite your existing config. This is expected (and encouraged) behavior. If you have local config file changes, you should put them in your config template.