Aber dann könnten die Dummuser sich nicht mehr gegenseitig mit lustigen bunten Mails bespassen. Das geht ja wohl gar nicht!

Warum code in e-mails? Für was müssen e-Mails überhaupt code fähig sein?

Erstens bedeuten bereits ASCII, UTF-8 oder sonstige Zeichensätze, dass eine Kodierung/Dekodierung stattfindet. Du liest ja nicht die übertragene Mail Byte für Byte. In dieser Hinsicht enthält eine Mail immer "code".

Zweitens heißt die Anwesenheit bzw. Übertragung von "code" nicht, dass er auch gelesen, interpretiert und ausgeführt wird. Wieso also kein "code" in Mails?

Auch der Sinn von html-mails erschließt sich mir nicht.

Mir erschließt er sich schon. Man möchte Texte im Allgemeinen gerne möglichst frei und praktikabel formatieren - so auch Mails. Dazu möchte man eventuell Bilder einbetten. Man kann jetzt lang über die konkrete Spezifikation der Auszeichnungssprachen, die hierfür infrage kämen, diskutieren. HTML in Mails wurde per zusätzlichem RFC als Auszeichnungssprache neben unformatierten Texten und Zeichensätzen standardisiert. Das lag vermutlich an der damalig bereits bestehende Verbreitung von HTML. Und da mit Browsern die nötige Software bereits existierte, um HTML zu interpretieren und darzustellen, lag der Schritt nahe, das für Mail anzupassen.

Natürlich sollte man aus Sicherheitsgründen in Mails nur eine kleine, sichere Untermenge von HTML unterstützen, d.h. u.A. also kein JavaScript ausführen oder externe Seitenelemente nachladen. Für eine erste Übersicht schauen und testen Sie doch mal welche HTML-Tags/Attribute in diesen Kommentaren zugelassen sind. In dieser Hinsicht sollten Mail-Klienten also nicht fähig sein, "code" ausführen zu können.

Bei verschlüsselten mails kennt man den Absender und [...]

Wer kennt den Absender verschlüsselter Mails? Wer ist "man"?

Die Felder des Mail-Header können lauter Kokolores enthalten. Wenn man Glück hat, ist die gesamte Kette der Adressen der MTAs unverfälscht. Sobald ein MTA über seinen Vorgänger lügt, wird es kompliziert. Die Felder From und Reply-To können vom tatsächlichen Absender frei erfunden sein.

Und auch eine Verschlüsselung hilft hier nicht weiter. Verschlüsselung ist keine Authentifizierung. Welche Art der Verschlüsselung meinen Sie? Cäsar-Verschlüsselung? Asymmetrische Verschlüsselung? Auch bei GPG kann eine angehängte Signatur schon vom tatsächlichen Absender absichtlich irreführend sein, oder gar auf dem Weg zum Empfänger verfälscht worden sein. Sie setzen hier voraus, dass die Vertrauenskette bereits hergestellt wurde.
Schlagen Sie also implizit vor, dass man Mails nur noch von denjenigen erhalten kann, mit welchen man über andere Kanäle bereits eine Vertrauenskette herstellen konnte? Ich denke nicht, dass sich Mail so durchgesetzt hätte.

[...] bei unverschlüsselten könnten die server die Weiterleitung blockieren wenn code enthalten ist.

Dafür müssten die Server den Inhalt der Mails interpretieren. Das verschiebt also nur das Problem von der Klient-Software (MUA/MRA) auf die Server-Software (MSA, MTA oder MDA). Zudem zentralisiert sich so der Aufwand. Damit wird es aufwändiger einen Server zu betreiben. Die Kosten würden steigen. Außerdem liegt dann eine sicherheitskritische Stelle mehr in der Server-Software.

Die Frage, was "code" in diesem Zusammenhang denn überhaupt bedeutet, hatte ich ja bereits angeschnitten, siehe oben.

Auf diese Weise würde man eine der größten Einfallstore für Schadcode schließen.

Nein, so einfach geht das nicht. Bestenfalls verlagert es das Problem an eine ungünstigere Stelle, und so nebenbei definieren wir Mail grundlegend neu - durch massive Einschränkung der Features und RFCs (siehe oben). Da werden Sie sicherlich großen Beifall ernten.