Hi,
I also found this limitation, and my solution was to disable radio links and to replace them by a manual approach:
1. I disabled the call to (org-update-radio-target-regexp) in org.el. Well, I added a boolean org-inhibit-startup-radio-refresh, that works in a similar way to org-inhibit-startup-visibility-stuff. After this change, I still type <<<this>>> to define a title, but org doesn't handle it anymore
2. I created a
helm menu, that offers me all the radio links. I compute the list of radio links myself, through grep, by looking for <<<. It's easier than it seems, and very fast. The code (no explanations) is
my configuration, in these functions: anythingyhelm-fuente-etiquetas-radio-org, precarga-etiquetas-radio-de-wiki-para-helm
3. Often, when I want to refer to a title, I write in in cursive, /like this/. That's my way of telling myself „that's a link, you can manually search for it through helm“. The target will be tagged <<<like this>>>. I could automate this link-following but I don't mind typing for 1 or 2 seconds to go a header. I still use normal links (C-c C-l, :ID: etc.) if I want something that is easier to follow.
My system doesn't provide the same features as org's radio links, but I get an interactive menu with pattern matching and very fast access to all headers. I would still prefer the real radio links, with no limitations.
However, I understand that org-mode's approach is computationally harder. Whereas I'm looking for ONE target link through all my 100 files, org-mode is doing a regexp that looks for ALL target links in the current file. And I have around 20k radio links!. Grepping for 20k things everywhere is harder than grepping for 1 thing everywhere. Even GNU grep is slow (>25 seconds) if I use
a long regular _expression_ with 20k things inside.
In other words: since radio links don't scale well, I have replaced the real radio links (search for everything everywhere) with a directed approach (search for 1 thing everywhere).