What should be the general rule when a method is not supposed to be called in some situation, but it's execution does no harm to the program in general?
I see what could be a minor contradiction in your statement that may make the answer clear to you. Why is it that the method is not supposed to be called and yet it's execution does no harm?
Why is the method "not supposed to be called"? That seems like a self-imposed restriction. If there is no "harm" or impact to your API, then there is not an exception. If the method really should not be called because it may create invalid or unpredictable states, then an exception should be thrown.
For example if I walked up to a DVD player and hit "stop" before hitting "start" and it crashed, that would not make sense to me. It should just sit there or, worse case, acknowledge "stop" on the screen. An error would be annoying and not helpful in any way.
However, can I put in an alarm code to turn it "off" when it is already off (calling the method), that may cause it to enter a state that would prevent it from properly arming it later? If so, then throw an error even though, technically, "there was no harm done" because there may be problem later. I would want to know about this even if it didn't actually go into that state. Just the possibility is enough. This would be an IllegalStateException.
In your case, if your state machine can handle the invalid/unnecessary call then ignore it, otherwise throw an error.
EDIT:
Note that a compiler does not invoke an error if you set a variable twice without inspecting the value. It also doesn't prevent you from re-initializing a variable. There are many actions that could be considered a "bug" from one perspective, but are merely "inefficient", "unnecessary", "pointless", etc. I tried to provide that perspective in my answer - doing these things is not generally considered a "bug" because it does not result in anything unexpected. You probably should approach your problem similarly.