Because we don't want client implementers to be forced to have to jump through end-to-end crypto hoops if they don't want to. The simplest way to send a message in matrix is:

curl -XPOST -d '{"msgtype":"m.text", "body":"hello world"}' "https://matrix.wherever.com/_matrix/client/api/v1/rooms/$roo...

...and we'd like to keep it that way. But you can always insist on only ever communicating with folks who are on E2E crypto clients if you so desire.

Is that the same way I can always insist on only ever receiving PGP-encrypted e-mail?

Not quite - as PGP is a pita to use, and not a formal part of the SMTP spec. So refusing to read non-PGP would be suicide. But if it was considered table stakes to implement the crypto option of the spec, and all the decent Matrix clients out there did so and sent end-to-end encrypted by default, then it'd naturally become the default. In other words, if you gracefully upgrade chats between capable clients to be end-to-end by default, everybody wins.

If you really believe that, then I feel sorry for your users. Privacy is a public health issue: https://www.theguardian.com/technology/2013/may/21/privacy-p...

In the absence of some forcing function, the trend is for it to get worse, not better.

Back in the day it was often optional due to the additional processing that it required.

That was indeed a thing in the days before AES-NI or simply having 1.4 billion transistors on a chip.

But in my day we've been spending years fighting this sort of short-sightedness: https://www.ietf.org/mail-archive/web/rtcweb/current/msg0274...