I've never found this terribly complicated or error prone?
For the most part, an occasional one-line clobber list comment seems to keep track of nearly everything I need to know about this.
In practice most of my call trees aren't very deep at all, or fairly well contained. I'm struggling to even think of a situation where the structure would need to change so often and so much that it would sound like the problem you seem to be describing.
I can confidently say that I haven't felt it was inadequate in my last 10 years of using cc65.
It also seems adequate for the extensive cc65 library codebase, which also operates using a global collection of static variables. (Incidentally, it uses org only once, and it's to place a labelled structure on a memory mapped register, which I think is an interesting application.)
.
Anyway, like I said, glad it works for you. I appreciate the perspective you've provided as to why you want to do it, and I will gladly recognize that it sounds productive and useful for you. ...but you haven't persuaded me that I should use it, or that I should recommend it to others. I still advise against using org in general with this toolset. (On more specific cases I'm sure there's a situation where I could be persuaded.)
Of course, I also wouldn't advise to remove/change it from a large codebase where it's working well either. If I were adopted into an existing project, I would continue doing things the way they were.
From my interpretation of OP's question, superficially it felt to me like they were probably using org unnecessarily. I can see how it looks naturally like your apparent paradigm for using it heavily, but for me it sticks out, especially the way OPs problem was described. I don't know if OP is starting out, or already in deep, or what, but it's my honest opinion that it's generally best not to work against the linker like this.