Apart from the nifty responseTopic demo you did (and the one I did some time back), where V5 will be a big bonus is in the future when you have a stable running install, sending number values (not JSON) and realise you absolutely must have some additional data (like a 'timestamp' or 'gps-lat-lon' or 'device-owner') adding to the packet - however - you MUST NOT break the other 63 systems that expect a number value in the payload. This is where User Properties comes in very handy.
Also, another good feature you dont realise you need - until you do - is expiring retained messages. Imagine you publish every 5 mins the fill-level (retained) but the publisher breaks down or is offline for 6 hours - when a client connects, it will get a value that was last updated 6 hours ago. With Expiry set, the broker will throw the old retained message away after the specified time (probably best set to 6 minutes for this example).
Lastly, what will become more useful (in time) is the ability to auto parse the payload by checking the Content Type value.
Combining these feature together creates even more possibilities. e.g. suppose SERVER1 wants to send a control message to MQTTSERVER and expects a response in XML. and SERVER2 wants to send a control message to MQTTSERVER but can only handle JSON, they can both make use of the Content Type and Response Topic to ensure thats what they get.
