The issue is that we can't just think about what you or I personally want.  We have to think about the impact globally.  This is a good sized API feature addition.  If we just slam some random enum names in to place and they end up not making sense later, we can get cornered into a common law type of implementation we can't change.  It's important to spend the time to ensure it makes sense up front.  There are plenty of events already implemented that everyone just groans at because no upfront thought was put in to them.  We are trying to prevent adding any more examples to that situation.

Your personal motivation may be a bugfix for your plugin, but the impact of this PR is greater than just you.  All this feedback is not really "last minute".  PRs have been poorly managed to date and Bukkit has empowered some dedicated people to working through them.  All this discussion is the result.  It's a definite increase of feedback suddenly, but this could still take some time to hash out.

Deciding on what the enum should represent should really be driven by use cases.  So let's explore another option, why have a cause at all?  Leave it off for now and it can be added later if needed.  Keep isGaining instead.  If a plugin needs to determine cause they can monitor other events and deduce accordingly?

I was hoping you'd clarify why you thought a cause enum was needed.  I'm having trouble seeing a purpose and without one the enum could be defined any number of ways for any number of  guessed at reasons.