What's the point of MQTT persistence?

I am looking into the persistence option right now. As a start, I only want to use it to restore all item states on reboot.
After reading a bit, MapDB seemed to be a good way to start - until I went to install it and saw MQTT persistence below it in the add-ons list.

If I understood correctly, I can store the state of MQTT items (of which I have a few - but also several other items and values to store) via MapDB - what is the upside of MQTT persistence?

I’m going to take a shot at this but don’t take this as gospel truth, just my guess. The mqtt broker has a persistence file of it’s own. (at least the embedded one does). When you have configured a topic to retained=true the value is held (I assume in the persistence file). I think the idea is if you have a mqtt client that only checks in with the broker on occasion(because it is battery operated and asleep for instance), when it does respond, the broker sends the most recent value (that has been retained)
I believe the point of mqtt persistence is not to restore values at start up.
If that is your goal, MapDB is the tool to use for the job. It is an internal database (making it fast) for doing exactly that

It’s a legacy holdover from years ago. It was, IIRC implemented before the MQTT 1.x binding had support for event bus. The purpose of it was to publish command and update events to MQTT topics so some other service that uses MQTT can keep up with what’s going on in openHAB.

Unfortunately it was only one way though so you would have to manually configure Items to subscribe if that remote system needed to send updates or commands back to the OH. The MQTT Event Bus came along which does support this two way flow of messages making the MQTT Persistence add-on redundant. But some people used it so it was kept.

It’s write only so you can’t use it for anything you would normally use persistence for like restoreOnStartup or getting an Item’s previous state or the time of it’s last update.

There is no reason anyone should use the MQTT Persistence add-on anymore.

That’s OK reasoning but it never worked that way in practice and it really won’t work like you describe. It was and only ever was a hack built to get OH events to some other system (e.g. a custom UI) which was a stop-gap until the MQTT Event Bus configuration was created in the MQTT 1.x binding.

Much of your reasoning is tinged by more recent events in the world of MQTT on openHAB with the discussions over retained messages and restoreOnStartup. Back when the MQTT Persistence add-on was written (at least 5 years ago) retained was almost never used by openHAB users and restoreOnStartup worked more intuitively with the MQTT 1 binding.

Ultimately, the add-on was a hack along the lines of Expire binding which implements something that should have been implemented in another way from the start. Unlike Expire, eventually it was re-implemented.

Interesting historic note: The original cloud connector add-on in OH 1.x was also a persistence add-on used to configure which Items were exposed to my.openhab.org (we had a different URL and server back then) was controlled by a .persist file. So misusing persistence add-ons in this way was not unprecedented.