The "temperature threshold" is degrees, but it's tenths of a degree Celsius. The manual explains this parameter (Z-Wave parameter number 111) in a bit more detail: https://support.inovelli.com/portal/api/kbArticles/407409000001893293/attachments/1abnfb15f8d4f293f4937b017f9135a0e3f4c/content?portalId=1ce1db55e4825f16146555b24f0f1753cbf5f7d83ca0a3d8b31013b2a2d69e1f&inline=true. I'm surprised the wording isn't a bit better elsewhere--I had to look this up, even though I have that sensor, because I also found it confusing. 
So, the default of 10 means 1 °C. However, you can also configure time-based reporting (the "Interval, in seconds..." setting, or parameter 101), or disable either or both. I think the default here translates to 2 hours, so by default, you'll get temperature reports every 2 hours and whenever the measurement changes by 1 °C. (The wording in the driver kind makes it sound like it's one or the other, but I don't see anything in the manual/parameter docs that suggest otherwise.)
As for "reports," that's the Z-Wave term for a message that the device sends to the hub. So, the device will send a report/message to the hub according to the above settings as needed. Then, the device driver on Hubitat will do the appropriate thing with that information, which in this case would be updating the "temperature" attribute on that device. On the Hubitat side, if this value is different from the previous one, Hubitat will (by default) cause an "event" to be generated, meaning that any apps/rule that "subscribes" to the temperature attribute for this device would wake up and do whatever they're configured to do, if anything. This is similar to how the "motion" attribute, which you might be more familiar with, works: the sensor sends reports for activity/inactivity to the hub based on real-world events. When events (changes in the attribute's value) happen on Hubitat as a result, apps you may have configured like Motion Lighting will respond accordingly.
For the battery reports, I see the driver parses a battery level and will update the "battery" attribute value as needed. (BTW, you can see all of the attributes and the device/driver's current value for them under "Current States" on the device page: "Devices," then click/tap into the Inovelli 4-in-1 sensor's page). I don't see a specific way that the "low battery threshold" parameter from the device is used in Hubitat, unless that's when the sensor just sends "0xFF" (or 255) as the battery value instead of the actual percentage, which Hubitat's driver will log as "low" and where it looks like the driver will interpret that report as 1%. In any case, on Hubitat, there's no reason to rely on this threshold--you can create an automation based on the actual "battery" attribute value. I'm assuming that must be required by Z-Wave spec or something the manufacturer put in to be "nice" for users of hubs/controllers with less control (the hub/controller could respond to this event in some way; I don't see any way Hubitat does), but that's my guess. If the first part of my guess is also correct, then setting this too high might prevent you from getting actual battery level readings from the device in favor of "1%" reports when the threshold is crossed.
Battery reporting is notoriously unreliable with most devices and lithium batteries in general, so I'd probably avoid depending on it too much (I like to monitor device activity instead and get notified if that stops as a hint that the device may have a problem), but that's another story.
