CORBA (as was DCOM) provided an object model where the client would make method calls to object by identity. This provided "locality transparency" — an object looks identical in the client as in the server. The client object is just a "stub" in CORBA parlance (or "proxy" in DCOM, if I remember correctly), and method calls are transparently translated to RPC calls. The consequence of this is that a client can hold onto entire object graphs, and gets very tightly coupled with the server. For example, a single client can keep tons of objects "open" inside the server just by virtue of having references to them. Very careful tracking of object references would be needed. Both CORBA ans DCOM use explicit reference counting; if a client gets this wrong, it can cause memory leaks inside the server. Not great for scalability, and a big weakness in terms of security.
gRPC is more like DCE RPC or Sun RPC, while leveraging a bunch of the web stack which didn't exist back then. There's no denying that technology is cyclical in some ways, of course. But we're not exactly coming full circle. We bring back some things and integrate it into the new stuff. The tooling around gRPC is miles ahead of what we had back then, while being based more or less on the same principles.
Interestingly, there's a similar (but maybe more depressing) cyclical story with dynamic vs. static typing in programming language. Python, Ruby, PHP, etc. allowed more people to shift away from commercial tech stacks (especially the horrific Java app server stuff in the early 2000s) while building out super-productive web frameworks. JavaScript allowed us to write web apps that were capable of competing with desktop apps. But in the process we gave up static typing. Millions of person hours have been spent in blogs and discussion boards defending, and extolling the superiority of, dynamic typing — yet this was found (in my view) to be a fallacy, and something of a shared delusion among developers drunk on web frameworks like Rails.