It's meaningless to say "too much state" in the abstract without understanding what the state is and why it exists.
dbus was widely adopted because it solved certain problems that were previously unsolved, by making different tradeoffs vs previous solutions.
Anybody can show up and say "oh that tradeoff has this downside." That's why it's called a tradeoff.
Anyone on the Internet could prove me wrong by showing the code which has the pros without the cons. That's the beauty. Everyone would jump to use a best of all worlds solution like that. Meanwhile, people are using a solution that exists.
In my view, the client libs could be designed to better support reconnection but ultimately the app has to handle the case. Neither the daemon nor the protocol are the source of the "restart problem." The problem is that handling restart in N different codebases, with none of them ever buggy, is not practical. It isn't impossible, but nobody who has actually written code, to date, has decided the cost:benefit ratio holds up and proceeded to tackle this.