If you don't service an interrupt in time, you normally get:
- lost data (buffer overrun, buffer underrun)
- lost timer ticks

Of course interrupt latencies matter. You can't run your processor to hard - you must guarantee that when every little thing adds up, the processor is still fast enough to service each interrupt within the required minimum time (and definitely until the next interrupt from the same sources) and still have enough time to do the "main" tasks enough times/second for your requirements.

If you work ad a McDonalds you must be able to make new burgers at least as fast as the order desk can take up the orders. If not, you will either get a growing queue of back-orders, or you will start to loose orders.

Same thing with the order desk. They must also be abke to service arriving customers at the same speed as new customers arrives. If they can't, then the queue will grow and you will loose customers that will turn in the door.

It is your job to figure out all the timing requirements of your program. And it is your job to figure out if your software implementation fulfills all these requirements. And it is the people who requested the product who may add rules that some specific events may possibly be dropped to prioritize other things. But without explicit documentation that some events may be dropped, the design must be made with the assumption that no events may evern be dropped.