If you don't care about policies then all those things in X can be a good thing, but if you do care about policies then Wayland could allow for a better design, at least it seems that's what GNOME and KDE are aiming for anyway since their policies are very well established at this point, and they don't really seem to care about breaking ICCCM and other such things.
As for dbus, your solutions would work for some things, but would not have exactly the same semantics as dbus and would come with their own set of issues, and requires building several more infrastructure pieces, some of which you just described. You could build those but it likely wouldn't fit the same use cases as dbus. If you're sending messages that you expect other clients to parse then you still need to agree on a wire format and marshaling library, you can't get around that. If you ask me dbus itself doesn't require much infrastructure at all, you should consider reading the source code for the dbus reference implementation at some point because it's actually pretty small and stable. And I don't understand what you mean by re-implement POSIX IPC analogues, dbus is essentially just a wire format for Unix domain sockets and a message bus that routes the messages, it doesn't re-implement anything. If you want to use dbus from shell scripts, you can use tools like dbus-send and busctl, or you can try to use something like that dbus fuse filesystem -- the nature of dbus makes it map pretty well to that, there's no reason you can't have both a message bus and an easy interface to access from shell scripts.
(Also just another nitpick here, the systemd developers are not the dbus developers, and systemd-logind doesn't take over the init process, that is its own smaller daemon)
If you want to read more, see some comments from the original dbus author: