sorry.. I was supporting your arguement not suggesting your position was incorrect.  The original position is that class methods are not your friend and maybe shouldn't be used.  I was suggesting without classmethods we wouldnt have SQLProcs that are functions.  

When thinking about IRIS we have both Objects and SQL.  I tend to lean towards the SQL world.  Not because I dont use Object but I'm mostly focused on storage, performance of retrieve/reports/obtaining a list of records.  I think of IRIS in terms of performance as

1. directy global access/hand written objectscript code.. likely fastest but relatively hardest to write as you have to have intimate knowledge of the structure of globals, what indices are available, what are the statistics between globals.  It's not hard, its just more intense to write.  At the same time for better or worse this code could be stuck in time.  For example, if you weren't aware of $SORTBEGIN/$SORTEND but did not use it.. welp it will never be utilized.  On the otherhand if back in the day you had a SQL statement which didnt even have this function but then there is an upgrade and these functions exist then the SQL code is regenrated and you get the benefit.
2. SQL ..more readable, easier and faster to write.. optimized to just what you specify.  If a table has 200 columns(and yes plenty do) if I SELECT A,D,E FROM Table the generated code is optimized to only get those columns.. but not nearly as fast as #1..but maybe with PARALLEL query support it could in fact be much faster.  In a SELECT statement LOCKS are not by default implemented.
3. Objects.. even more readible, maybe faster to write but maybe slowest(and when I say slowest this is a relative positions..I'm not saying Objects are slow).  When you %OpenId an object it has to load into memory all 200 properties(taking that table/object from #2) so that you can later write oref.property199.  It simply doesn't "know" what you are going to use later so all of the properies have to be "swizzled" into memory.  %OpenId actually has 3 parameters in the formal parameter list including the Concurency option.  Many folks do not bother to specify the Concurrency option.  Do you always needs a lock?  Not sure but I dont think many even consider this.

I may be miststating some things above but after 35 years working on InterSystems technologies this is how I think.

Strangley enough I often times see people fall into a trap where they think every method in a business host class(Service,Process,Operation) has to be an instance method but when you study the code there is nothing in the method that depends on an instance being defined.  When this strategy is done it's basically reducing the amount of reusability so I actually look more towards ClassMethods unless they truly are instance methods.

I agree with Rich and see that it would be obtuse/challenging to create SQL Stored Procedures if we didnt have ClassMethods.  Does this mean we simply cannot have SQL Stored Procedures?