Can't comment about FRP, but can tell you that events
can ripple through an entire system, but don't
have to.
The back story to that is that you need to put some effort into design. I've been using an event-based design as the basis for all native apps I've built since 2004, and it's evolved into something that's predictable and obvious - primarily because of separation of concerns.
For a simple example, here's a short description of the client I use for my blog: https://www.wittenburg.co.uk/Diagram.aspx?id=5919c0a5-dcb5-4...
The blog post describing the diagram is here: https://www.wittenburg.co.uk/Entry.aspx?id=5919c0a5-dcb5-4e5...
In this approach the model (I call them application entities) is the only part of the system that can raise application-wide events. These are limited to things that happen to the model, eg. Login; per collection, things like Selected, Added, Removed; and per entity, things like Saved, and Deleted.
The UI raises events (keyboard/mouse/etc), but their scope is limited to the UI. There's a service agent that abstracts asynchronous calls to a service, and it raises an event once an async call completes, but that is only visible to application components (Operations, in the linked post).
My specific implementation of this design is based on the architecture of Microsoft Office apps (the idea started formulating after working with Word's document object model).
It's clean and like I mentioned above, predictable.