You wouldn't send a JSON RPC request with GET. JSON RPC requires you to send a JSON object in the body describing the method you are calling and the parameters, and the version of JSON RPC you are using. That requires a POST.
You could just have a single /rpc endpoint that takes POST and use that to serve multiple procedures for all sorts of things.
Yeah OK, so JSON RPC avoids this particular problem by simply not supporting GET. But that is kind of throwing the baby out with the bathwater, since GET is quite conventient when used appropriately.
Consider what would happen if he didn't want to merely "toggle" his door, but rather have it closed, definitively and once and for all.
Could he do that with /toggle? Does he know the state of the door well enough to know if toggle is the right command? Can he even trust the state of the door being told to him? What if it's already closed and it opens instead?
No. The only way is to send a message that directly says "Close the Door", with no room for ambiguity on his intent.
JSON RPC excels at this, and in putting the door in whatever state he wants, maybe half way, or 3/4. How would you do this with "convenient" GETs? Use query params? Multiple endpoints? By this point, idempotency is in the rear view mirror and you're well on your way to having a clunky garage door system fraught with bugs and strange edge cases.
I don't really have anything against JSON RPC but it is just a standard for encoding a method name with dynamically typed parameters. You can say "close the door" in JSON RPC, or you can just post the string "close the door" to an URL. It doesn't make the service more robust or reliable to use an extra layer of wrappers.
You could just have a single /rpc endpoint that takes POST and use that to serve multiple procedures for all sorts of things.