Eventually you'll reinvent SOAP and be in for a world of pain and suffering with slightly incompatible or overly complex tooling.
We program things to make our jobs easier. If it looks like a call, takes args like a call and returns values like a call, it probably is a call. If you have nothing against a call, you have nothing against RPC. Give me TCP, SMTP-over-SOAP-over-HTTP, XML-over-PigeonPost, whatever. I’ll hide this nonsense in an rpc.<langname> file and turn it into a call, because calls are my main programming instrument. Everything else is just an annoying noise that either takes a page to perform or gets wrapped into the exact same parametrized call.
As you application grows
No, you have to design it in from the beginning. How can someone not think of exception borders, API contracts, safety/idempotency and versioning even for a single call?
I see that errors are handled well by telefunc. Other issues are easy to do in the same way you do it in REST/POST, i.e. foo(…, new_arg), foo_v2(…), plus some docs. It is literally just a different form with the same content, which is closer to the language and doesn’t require pages of almost identical parametrized wrappers.
I’ve been burned in the past by RPC (mainly SOAP), but will take a deeper look and try to keep an open mind. Building “REST” APIs is damn tedious.
Maybe you want something more barebones, maybe you want to leverage existing protocols. These days, it's kinda the wild west out there in terms of web standards it seems, so go nuts I guess.