I never needed a library to use a process-state event-driven real-world approach.
What programming they teach in the first course levels was and probably still is top-down or big loop monolithic start to stop continuous code that waits for inputs to keep its place. Even multitasking code is written this way since the OS does the time slicing.
BWD shows timing a simple event that lets other tasks be run "at the same time" but with a small single block if code. Then state machine shows how to split larger tasks up and run a piece at a time to not block time and input event checks often enough to be responsive.
It gives you the freedom to write code as objects that run as needed and interact through variable values.
You can put the code to do with a button in one or more separate pieces, not interleaved in logic with what the button does as that gets passed in variables. The code for the button (that may contain debouncing) becomes interchangeable with code for other sensors like ultrasonic or capacitive sensors.
Code written as pieces can be tested and debugged and moved from a dev sketch directly into the state machine loop() without having to be fit into or directly called by any of the other pieces already in the loop(). What happens when you run it depends on how good you got it but adding and removing modules is easy that way.
If you have a chunk of code run a task that might take 100's of usecs, like an analog read or doing floating point math, then end that one with a return to run loop() again immediately.
You want loop() to keep with time and events and run a step towards a current goal at maybe 1000+ steps per second.