Yup! I would agree with this too. I've actually written an FRP library in Ruby[1] and it's not really _useful_ yet because of these kinds of issues. I was thinking about how I'd use it to build a web framework, for example, and I'm not sure it's a significant improvement.
Regarding >>=: yes, it's the 'bind' operator, and yes, it is really impressive. This is why monads are hard: they're so abstract that they're good for _many_ things. It's also why they're so great.
FRP strikes me as much, much closer to how Things Should Be(tm), but it still feels off somehow. Perhaps it's just too low-level. It should really part of a language's runtime, rather than exposed to the user. Right now, most FRP implementations kind of take over your system: you're always sweating whether this is a special reactive type vs your domain type. Even C#'s async/await (not quite the same thing as FRP) seems to have a similar effect, where the async function keyword propagates through your codebase quickly (caller/callee have to agree on this I believe).
FRP still feels like it's in the early stages, so I'm confident someone will find a better way to apply it. Right now it seems more palatable to non-bleeding-edge devs if you tailor it for specific use cases, rather than the whole thing at once. It may be the concept is too big to sell right now.
Regarding >>=: yes, it's the 'bind' operator, and yes, it is really impressive. This is why monads are hard: they're so abstract that they're good for _many_ things. It's also why they're so great.
1: https://github.com/steveklabnik/frappuccino