Hello Joon,
The `on()` method isn't a great fit for Futures (i.e. promises), since it is really a continuous event stream. Keep in mind that the security rules may also be initially valid, but later a condition could change that causes them to become invalid (i.e. a user's role could change while the on() listener exists, or data could change in a way to render the security rule false). You can't have a simple binary yes or no returned here.
We could just have the promise unresolved indefinitely until a failure occurred, never calling the success, but that would be pretty contradictory to the mental model expected by promises, and could create some strange error cases and unpredictable bugs when chaining then-ables together. So hopefully it makes a bit of sense why we didn't want to encourage this.
The best approach here would be to embrace the event paradigm, and think of this as a continuous stream, rather than a simple CRUD operation. If you're unhappy with that, it's not particularly hard to wrap the on() method and return your own promise, adapting the behavior as you see fit.
☼, Kato