Alternatively, if I am incorrect about this: then in what way?
You are comparing apples to oranges.
The email Header is most closely equivalent to the physical mail Envelope - even better, the email Header represents routing information that is not accessible to the recipient in physical mail. So it's not correct to say that email client's access to "envelope information" is hampered. In fact, by design, the important aspects of "envelope information" are injected into the Header, ensuring that email Headers contain routing information greatly in excess of what any physical mail recipient could obtain.
Some definitions (assuming US mail for simplicity):
email Envelope: The values transmitted using the SMTP HELO/EHLO, MAIL FROM, and RCPT TO commands. Any of these may legitimately change from one hop to the next.
email Header: The text transmitted after the SMTP DATA command, up until the first blank line, after which the email Body begins. This likely includes a From: (which may or may not agree with the Envelope MAIL FROM) and a To: (which may or may not agree with the Envelope RCPT TO) header. This email Header grows as each intermediate mail server prepends Received information, as required by RFC 5321 §3.7.2. In addition the recipient mail servers may record the Envelope RCPT TO by injecting a header such as Apparently-To, Delivered-To, X-Envelope-To, X-Original-To, etc. (but see footnote below).
physical Envelope: The From address (optional, upper left hand corner), the To address (center), originating postmark (upper right, over the stamp). There may be additional encodings of the recipient information such as the IM Barcode and the orange barcode, but those are both effectively more-or-less lossy representations of the To address.
Note that RFC 5321 §3.6.3 suggests that SMTP relay servers should never modify anything in the header and body except to prepend the required Received line. In practice, other headers get prepended, especially with intermediate anti-SPAM/malware relays.
Here's how the email Header incorporates necessary Envelope information
The SMTP Received header is prepended by each SMTP server and describes the Envelope information about itself and the previous server. Consider this entry:
Received: from mail2.example.com (mail2.example.com [192.168.3.4])
by lix-xx.members.linode.com (Postfix) with ESMTPS id 838CD4AE0
for <email@example.com>; Fri, 4 May 2012 12:45:26 -0400 (EDT)
This includes the EHLO/HELO hostname (the first mail2.example.com), the actual IP (192.168.3.4) of that system, and the DNS name that resolves via PTR (the second mail2.example.com). This information is useful for detecting fraudulent email.
More envelope information may be logged, as seen in this example:
Received: from NAM01-SN1-obe.outbound.protection.outlook.com
by smtp21.example.org (Postfix) with ESMTP id AF320401EE
Wed, 5 Dec 2018 15:28:59 +0000 (UTC)
Here the envelope RCPT TO was encoded using the FOR clause of the Received line. (Note that per RFC 5321 §4.4 only one entry is permitted, even when there are multiple RCPT TO commands.)
What's not preserved
The MAIL FROM and RCPT TO addresses are either not logged, or may be incompletely logged, into the header. This may be part of your "tampering" detection concern. It is a side effect of the fact that SMTP was designed to transport encapsulated messages that may have their own rich addressing and routing information before and after the SMTP phase of the connection. It's also something with no physical analog.
This design consideration may also reflect that SMTP was not designed to be trusted, simply to work. As soon as trust considerations arose, they were offloaded to other layers of the connection (PGP, SPF, DKIM, all of these occur "outside" the SMTP protocol).
Let's not forget
Any part of the header or body can be tampered with by a malicious relay. The more effort you put into making relays log security information, the more you're potentially relying on bad information. That's why each Received line reflects upon the previous relay, and not the one that's prepending it.
In other words, there's limited value to trying to load more trust into the relays.
As to logging Envelope RCPT TO in the Header, RFC 5321 §7.2 states:
There is no inherent relationship between either "reverse" (from MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP transaction ("envelope") and the addresses in the header section. Receiving systems SHOULD NOT attempt to deduce such
elationships and use them to alter the header section of the message for delivery. The popular "Apparently-to" header field is a violation of this principle as well as a common source of unintended information disclosure and SHOULD NOT be used.
The market has largely ignored this recommendation.