Yes, you need to deal with EMI and static bursts on your microcontroller inputs.

In practice switch bounce often lasts tens or even hundreds of milliseconds, and you need to space out the read process to cover the entire bouncing process if you want to avoid registering fake presses. Using basic averaging means your minimum input latency is going to be ~half your bounce time - which is often way too high for it to feel like real-time input.

If you want to achieve low-latency input, "act on first edge, then ignore for the switch bounce period" is a far better approach. It also conveniently solves the "press, then release within bounce period" problem where an averaging algorithm would completely ignore the button press.

Regardless, if the problem is an input that normally registers the state of a button except for noise for some time as it bounces when it transitions, 48 of those reads, the averaging and the 5ms latency that incurs are unnecessary with respect to the problem.

An averaging filter makes sense if you have a noisy analog input. For a button input that registers whether it is pressed or not except for a known noise around transitions specifically, ignoring the transitions immediately after the first one registered is not only faster (both in terms of latency and CPU cost) but easier to implement. It's also equally practical for switches with long bounce, where the time it would take for an average to favor a transition might be impractically long.

Latency is cumulative, so avoidable latency is never acceptable. Maybe the hardware will change. Maybe somebody will run your software in an emulator. That 5ms could be enough to push the total latency into the "annoying" level.

And even with no additional latency, 5ms is perceptible in some cases anyway. Microsoft Research has a video demonstration:

https://www.youtube.com/watch?v=vOvQCPLkPt4

Doesn't matter, their way is terrible one that adds latency for no reason.

There are 2 things here worth paying attention

* first "bounce" is user action * last "bounce" is stop of user action.

You can run action on first bounce then just ignore the button for whatver debounce period you deem satisfactory. But adding delay to start action is always wrong answer for debouncing.

Now the harder problem is the off of the button, especially if hold is also an action but "be off for at least few ms" usually handles it well and off time is not lag user feels

No. Act on first transition. Cool down period following. You did not spot something everyone overlooked for 100 years.

There are other situations but not for a button. There are inputs that might be continuously noisy where a sliding window / ring buffer rolling sample is the only way to tell the difference between states. But we are talking about binary input controls actuated by a person, not a thermometer or O2 sensor.