It is true that in case of a client-to-server single-hop deployment, e2eid can server the purpose, but since Diameter protocol supports multi-hop scenario, it uses hop-by-hop id to uniquely associate an answer to the request. A peer stamps a unique (for that peer) hop-id while sending the request, and when the answer comes back (carrying the same hop-id), it is able to extract the required information like the source of the request as well as its 'original' hop-id.
The protocol has to support the general deployment (which would involve relays between agent and server). It can't do separate processing for the special case of single hop deployment. Note that e2eid is required to be unique only for that 'originating host', so at the server (and at relays) there could be multiple requests with the same e2eid from different clients.
In your own case, even though today you have a single hop deployment, as the network grows, you may need a relay in between. With the right implementation, you can achieve that without any change to the application or protocol implementation, just by a configuration change.
