Many devices support MQTT for communication.
My proposal is to allow Hubitat to act as a lightweight MQTT Broker (e.g. via optional app), so those devices could work independently of an internet connection and any additional network components like a Raspberry Pi.
You are of course welcome to make any feature request you see fit.
However, in my opinion this one will never happen.
Hubitat is a purpose focused hub, and a commercial product at that, so it can't just use open source broker code easily - they would likely need to license or write their own.
As there are about 1000 items in the to-do list already, I can't see that ever happening. Especially since there are easy workarounds (external broker installed on rpi, vm, or container).
The alternatives like Mosquitto broker are already much more mature and agreeing with what @JasonJoel said about HE's todos it just seems like a better idea anyway. On the other hand running a client on HE is doable - if you haven't seen it yet check out @kevin's very interesting MQTT Beta 3 client...
@kevin's MQTT Beta3 client is a super cool general purpose client. For another example, of a very focused minimal client, check out this driver I made:
It's coded for one specific minimal purpose (controlling my DIY smart blinds) and shows how little code it takes to make a Hubitat driver use MQTT. I'd say it's even easier than making a z-wave driver.
Thanks for your replies!
While an MQTT client is definetly something I will require soon, I was really looking for broker functionality. One thing I like most about Hubitat is that it allows me to reduce the amount of moving parts in my setup, like e.g. proprietary Zigbee gateways. It's batteries included and self-sufficient.
Adding a dependency on additional hardware and/or the internet connection breaks with this simple setup: More stuff to monitor and an additional single point of failure 
Have you looked into Node-RED? In terms of a very super flexible "visual" control system it is amazing. It can act as master controller for HE and other systems as well. It has a built-in broker you can install called Aedes.
My experience: I set up Mosquitto running on a Raspberry Pi. It does not require an internet connection. It's just on my local network. After setting it up, I have never had to log back into the Pi or do maintenance even once.
Me too - I have it installed for a Personal Weather Station + owntracks.. working nicely. Communicates to NR which then talks to HE.
Can I say "me three"?
I will add something else. The Hubitat Elevation is processor limited relative to even an RPi4. Setting it up to be hammered by MQTT clients isn't going to give the end user a particularly good automation experience.
I got my Pi running with OpenHab for ages - and one day the SD card died and it took me quite a long time to get it back up and running. Too much time passed and I didn't remember all the steps.
Sure, but I'm not talking about dozends of clients, just a handful. It is a specially designed, simple IoT protocol. If you skipped all authentication, encryption and QoS stuff, it shouldn't eat up too much of the ressources (but that's just a naive assumption, for sure). I just like the feeling of having an all-in-one solution 
The problem with this suggestion is that Hubitat has little control over how the clients behave, so it will not happen on the present hardware.
Run HomeAssistant on the hardware of your choice - this will let you run an MQTT server on the same hardware. There are also ways to integrate Hubitat with HomeAssistant, using the MQTT client indicated above.
I believe Mosquitto is one of the most robust apps out there. Running it on other 'suitable' hardware is going to be near 100% solid, setup and forget.
I really don't think it belongs in the HE Hub although I agree it's tidier. I'm very much against that option, and the folks in HA land have also backtracked from that inclusion.
A broker 'appliance' is a useful and important device in your home automation setup and users who need an MQTT broker almost by definition are using multiple devices (clients). Making that dependent on HE stability seems to not sit right, particularly if you have issues as some still do.
Raspberry Pi with SD is always vulnerable but there are other options, and Pi4 can now boot from SSD which is much more reliable. I have had SD cards fail on Pi but it's expected and you backup around that scenario.
Nope. Using open-source project in a commercial product is perfectly fine. Depending on the license you may either do whatever you want with it or share the source code or make your modifications to the code open-source as well. And you don't need to modify a broker at all, so later does not apply. So, this argument doesn't stand.
The platform runs within a JVM (so that’s where Hubitat devices - real and virtual reside). Any hypothetical mqtt broker Hubitat hypothetically incorporated into the platform would have to live within those constraints. Along with whatever memory and processor constraints are imposed by hub hardware.
So it appears less likely that there’s a plug and play solution that can be dropped in.