What configuration did you have in mind?

The entire system bus is out-of-scope for the base directory spec, because it's system-wide, rather than being used by any particular user.

~/.dbus should probably stay as a hard-coded path relative to $HOME, because its purpose is to be accessed consistently from any session, so it can't rely on the XDG environment variables being set consistently. If we redo the autolaunch/dbus-launch mechanisms, possibly it could move into XDG_DATA_HOME, but before doing that we need to work out which usages are actually supported (multiple sessions for a user on one machine? session spread between machines, sharing an X server and an NFS $HOME? etc.) and I don't see that happening any time soon.

~/.dbus-keyrings has to be a hard-coded path relative to $HOME, because its purpose is to be used on TCP buses in conjunction with NFS $HOME, to prove that a connecting user is who they say they are, by writing to a file that only they control (analogous to ~/.ssh/authorized_keys); allowing it to be overridden by environment variables would be a security vulnerability.

/etc/dbus-1/session.conf could conceivably be overridden by a file in ${XDG_CONFIG_DIRS}/dbus-1/session.conf, although I'm having a hard time seeing why you'd want to - the session bus configuration is already more or less maximally permissive, so the only useful change I can think of is switching session buses to TCP if you're running sessions distributed across many machines sharing an X server and an NFS $HOME, which seems like a sysadmin job anyway.

Session .service files are already read from ${XDG_DATA_DIRS}/dbus-1/services.

I'm talking about ~/.dbus*, so that's very sad.