Multiple Event Methods for the same Event

I surely cannot answer your question; I am not even sure I understand them. In fact, I do not understand why you should break an event handler down into several equivalent handlers.

I mean: each handler would still have to check the event to see if it has to handle it or not. So, ultimately instead of

@EventMethod
public void onPlayerCommand(PlayerCommandEvent event)
{
	Player		player	= event.getPlayer();
	String[]	cmd	= event.getCommand().split(" ");


	if (cmd[0].equals("command A") )
	{
		processCommandA(player);
		return;
	}
	else if (cmd[0].equals("command B") )
	{
		processCommandB(player);
		return;
	}


	// and so on...


}

you will end up with something like:

@EventMethod
public void onPlayerCommandA(PlayerCommandEvent event)
{
	Player		player	= event.getPlayer();
	String[]	cmd	= event.getCommand().split(" ");


	if (cmd[0].equals("command A") )
	{
		processCommandA(player);
		return;
	}
}


@EventMethod
public void onPlayerCommandB(PlayerCommandEvent event)
{
	Player		player	= event.getPlayer();
	String[]	cmd	= event.getCommand().split(" ");


	if (cmd[0].equals("command B") )
	{
		processCommandB(player);
		return;
	}
}

Is there any gain?

Well, for sure there will be some loss: we can assume that listeners are held in some container which is then enumerated (and each listener called) when the relevant event is detected.

So, for a 50-GuiElement "dialogue box" (I am using the term in a generic sense) and for click events:
*) there will be 50 insertions in the container instead of 1 at dialogue box creation;
*) 50 deletions from the container instead of 1 at dialogue box destruction;
*) 50 function calls instead of 1 at each relevant event;
*) some code will be repeated in each listener handler;
*) 49 of those function calls will return without doing anything but after having tested that the GuiElement returned by event.getGuiElement() is not this (functionally equivalent to a 50-case switch in a one-for-all listener, but possibly slower).

Of course, a lot of details would depend on what precisely you aim at, but if the 50 GuiElements are there at the same time, they are presumably not 100% independent one for each other and some additional code will be required to let the GuiElements (or their parents) to communicate to each other the outcome of the events; more code to write, debug and execute (which also does not help code readability and maintainability).

I am not an expert of Java performance, but I would expect the CPU additional load to range from trivial/unnoticeable to sizeable depending on how many listeners there are, how frequently this happens and specific implementation details of RW code and of your code.

However, the whole concept does not strike me as an improvement; I understand that handling, say, click events for 50 elements may lead to a very large method; I personally would address this by splitting the method with local method calls when necessary.

So, for instance:

@EventMethod
public void onGuiClick(PlayerGuiElementClickEvent event)
{
	Player		player	= event.getPlayer();
	switch(event.getGuiElement())
	{
	case toggleAButton:		// simple: process directly
		aValue = !aValue;
		break;
	case sellAButton:		// complex: call a local method
		doSellA(player, aValue);
		toggleAButton.setVisible(false);	// no more A!
		break;
	// and so on...
	}
}