I guess the distinction is that, as I said above, they don't see the content (unless, again, the clients leak the key). And it is an important distinction, because everyone will emphasize the importance of an encrypted connection (read: https). Which is not e2e.
As far as I could decode, the point here really is just to add this service to help their users who came for the password manager. But I also had to watch their video to confirm that the key was in the url.
The password/key never hits the Bitwarden servers. Bitwarden servers are just storage buckets for encrypted payloads. The server is never involved in the encryption or decryption process; this is the case for Vault, and now Send. All encryption and decryption is handled exclusively by clients.
Note the URLs used; all the important bits are contained in the fragment (after the "#"). HTTP clients do NOT send the fragment to the server; a "#" and everything after it is stripped before being sent to the server. Bitwarden's Send URLs contain an identifier as well as the decryption key in the fragment. When you load the page, JavaScript is able to read the fragment; an async request is made to fetch the encrypted payload using the first half of the fragment (ie. the payload's unique ID). Then the client–in this case JavaScript–decrypts the contents using the second part of the fragment as the key.
As far as I could decode, the point here really is just to add this service to help their users who came for the password manager. But I also had to watch their video to confirm that the key was in the url.