Depends entirely how you would define "practical reason" and how narrow or broad you understand the term "class". Is the mere existence of method-only classes in a runtime or framework (such as System.Object in .NET/C#, or java.lang.object in Java) already "practical reasons" enough to answer your question? Does the term "class" in your question include abstract classes and/or static (uninstantiable) classes, or only instantiable/concrete classes?

Those are good points. When I posted the question I was thinking of 'only instantiable/concrete classes' but you bring up some additional cases. The reason for the initial question is that I was reading through some code in a language that allows functions as well as classes/object and I go to wondering what design considerations would one think about in deciding whether to leave the functions as single functions or group some of them as methods in a method only class.