The example was perfect for the intended purpose, and illustrated the question
perfectly as well.  I disagree that it should have been longer.

OTOH, the factors that distinguish the choice of static or not tend to emerge
only in somewhat more complex circumstances.  It is not didactically necessary
to provide new SSCCEs for those circumstances; it suffices to outline the
differences from the original example and how they would influence the decision.

For example, a class dedicated entirely to methods that receive all relevant
state from method arguments would and should declare those methods static.  A
class that wishes a method to be overridable, that is, to display variant
behavior polymorphically, must declare such a method at instance level even if
all state arrives in the arguments.  Such a class will also be intended for
instantiation.

Factory methods for the class in which the factory appears should be static.
(Factory classes with instance methods are a different idiom.)

Absent those rules of thumb, a class intended to be instantiable might prefer
instance methods to static methods, if only to reduce the need for two ways to
invoke methods in the code:

 Foo foo = new Foo().
 Baz zesult = Foo.act(); // act depends on no instance variables
 Bar result = foo.transform( zesult );

vs.

 Foo foo = new Foo().
 Baz zesult = foo.act(); // act depends on no instance variables
 Bar result = foo.transform( zesult );

For me at least, the presence of an instance variable makes it natural for
that instance to own all the behaviors, even ones that might be implementable
at class level.  Even then, some behaviors so clearly belong to the class as
such that it just makes sense to make them static.

I'm sorry I called you example dumb, and I hope you didn't take any real
offense.  I just found your example entirely too brief to give me an
idea what you were really asking.

But without some context, it's so hard to fix on just one element.
Rather than a long SCCE, you could have posted a question about the use
of statics in the Java API.  That's large, and some people here might
actually know why certain methods are encapsulated where they are.

Like, why does both javax.swing.SwingUtilities and java.awt.EvenQueue
have the same (static) invokeLater() method?  Kind of an interesting bit
of history there....

Among the things I like about this advice is that it explains clearly what
refactoring is, and how to do it, at a good introductory level that still has
meat on it.  I will use explication along this line when I have to explain to
someone what refactoring is.  Thank you.