I think new users might not appreciate the difference between similarly named terms and then choose the wrong one to their detriment. It seems better that they should later learn of shared technology that's not clear from the naming differences than be surprised by differences in security properties that they incorrectly assume from similar names. (Perhaps more generally, the naming should reflect how users---broadly construed---should think about these things rather than the mental models that are useful as developers.)
It is actually for usability that I dislike making unnecessary distinctions. “Onion service” makes it simple to clients: xyz.onion = service accessible only through Tor.
And the problem for servers doesn’t seem so bad. Setup process: User: I’d like to set up an onion service. System: Would you like a hidden/protected/obfuscated onion service or a direct/exposed/peeled/flagrant service? Choose a direct service only if you want to expose the server location in order to improve performance [and security] for your clients. (Default: hidden service) User: I don’t like reading, I’ll just go with the default.
The point is that these security/performance choices should not be exposed to the clients, but they can be safely exposed to server operators.
Aaron