It does not matter if you do the rounding in C++ or Python, a float is a float in any language and if a particular number cannot be represented exactly to the precision you specify by the systems FPU then it will give you the closest value up or down that it can use to represent the value. Here is exactly what happens if I change the DLL and plugin as you proposed doing round 2 in Python:
09:34:33 System.Mute 59.619999999999997
09:34:35 System.UnMute 59.619999999999997
09:34:39 System.Volume 62.740000000000002
09:34:40 System.Volume 59.619999999999997
09:34:40 System.Volume 56.490000000000002
09:34:41 System.Volume 53.369999999999997
As you can see, python would also require the use of a string in order to store and represent exactly to the precision you desire seeing. Anytime you have ever seen a result different than this with a floating point value it is being printed and Python is auto-converting the value to a string for you. So, to get perfect print with the desired precision it has to be a string, and we are back to this new version since it will probably do the rounding and string conversion more efficiently in C++.
I think that the new version will be OK. I did not change the return format of SetMasterVolume or ChangeMasterVolumeBy... these still accept and return Float without any rounding exactly as before so they will remain backwards compatible. I only changed the new event's payload to string rounded to two places. Since the events are new no one will have backwards compatibility issues. It does look a little better in the logger, and I am sure it will be less confusing to people who are not programmers by nature. Also, I would predict that most uses for this event payload will be for OSD and volume synchronization scripts with serial control which will most likely use the string version directly anyway.
Finally... if we put this out there and later enough people provide reason to instead return the float, we can simply change it back at that time.