Spoiler alert: not a lot, actually.
Why does data volume matter?
In the early days of an IoT product (say, the first 10 devices on the lab bench or the first 100 devices in an early trial), it's normal to have lots of telemetry streaming out of your devices.
It makes sense - during R&D and proposition development, you need to see everything so that you can prototype, debug, and learn. As you don't really know what you need to see or store yet, your default will be to turn everything up to 11 and send and store it all - the benefits large and cost-negligible. Battery readings every second? No problem.
You'll revisit this decision as soon as you plan rollout and scaling. The "costs" we consider here are mostly financial, though ont he device side using precious battery-life or network bandwidth can also be considered as budgets you need to fit within.
Ever considered how much energy (and therefore money climate change) it takes to transmit 1GB of data across the internet? Here's an interesting meta-analysis we quite like.
If you have a battery-powered device or are connected via a low-bandwidth network such as LoRA, then you'll revisit it real quick, as your solution simply won't work or be cost-effective unless it can be frugal with data. But even if you have the luxury of having a mains-powered device connected via a nearly-free high-bandwidth wire then data volume will still, in time, become a topic that you ought to give some thought to.
Note: while the focus of this post is on how little data you need to do effective device and operational management, many of the suggestions here are applicable to application data, too.
What drives data costs?
Producing data in the device:
Before you can send data, you need to calculate it, which means consuming battery-power.
Transmitting data from device to the cloud:
Each transmit event consumes energy, shortening the life of a battery-powered device. Cheap wireless networks tend to be low-badnwidth (some allowing only bytes per day!) providing a maximum within which you must fit both your application and your management. Fast wireless networks tend to be expensive. Even if you're lucky enough to freeload on a link that someone else is paying for, such as a B2C product connected to consumer broadband, you need to ensure you remain a negligible fraction of their bandwidth.
Ingesting data into the cloud:
Although cheap enough on a per-dye basis, every time data arrives in the cloud a whole slew of service costs are incurred - restoring MB or GB of server context, performing authentication, etc - even for just a few bytes of payload.
Storing data in the cloud:
Cloud storage is pretty much free these days and unlikely to be significant in your calculations, as long as your data isn't video.
Querying data from the cloud:
Touching an appreciable amount of data in a reasonable time may requires hundreds or thousands of servers to be spun up for the duration of the calculation.
You might also be interested in....
Pricing your IoT service - there's a handy calculator for estimating your costs!