I tried to trace the call that does a full refresh and got as far as
forge--post-submit-callback.

Even though the operation is async, It adds a lot of friction when I'm
running through a list of topics and replying/closing each one. Emacs
still blocks when the sentinel runs, some magit-status buffer state is
disturbed etc.

Commands such as forge-topic-state-set-completed and forge-topic-set-labels do not use forge--post-submit-callback. They use forge--set-field-callback, which only updates the affected topic. (This does not apply to Gitlab, there we still do a complete API pull.)

Apparently that is still too slow for your taste (and/or given the size of your database and/or network speed). Unfortunately there is nothing I can do about that, not in the short run at least. Also, I just labeled some topics individually, and while there is a bit of lag, I find it quite manageable. But that's me.

Is there a reason that Forge pulls all topics and does a "full" fetch
from upstream whenever I perform some action in a single GitHub repo
topic, like

• forge-post-submit (C-c C-c in forge post buffers)
• Changing the state of a topic (open -> closed, etc)

In the first case this is done because after we create a pull-request, then we also fetch data using git (in parallel). That also takes a while, so we might as well make sure the API data is also up-to-date. We could avoid doing that when creating an issue or discussion, but even though we don't fetch git data, it seem reasonable to me to make sure the API data is up-to-date in those cases too.

Aside: where is forge-post-submit-callback-hook defined? I couldn't
find it, and it appears to be run in forge--post-submit-callback.

Hooks do not have to be declared. If I add a hook mainly for the benefit of a single user (here #182), then I usually don't declare it, to avoid advertising something I am not (yet?) fully convinced is actually a good idea.