Can anyone tell me what the overhead is of having a method in it's own class in an include, compared to having the method in the main .pde?
This is about the OO paradigm called encapsulation. A class works more or less as a black box with a strict interface, it abstracts a piece of functionality. The interface of a class tells you WHAT it can do for you but not HOW it does this internally. This prevents interference between internal code of classes and main program. If all code is in one sketch - or worse - all in loop() then there is a bigger chance of interference between all variables. It is not that there IS interference, is about a chance.
The abstraction of a Class is in fact no different as calling a function e.g. sin(x). That is also a (well known) abstraction of some complex math you probably don't want to write yourself. In arduinoland there are many classes e.g. for sensors that hide implementation details like how to communicate, reset, calibrate and get a meaningfull value out of the sensor. Another advantage of classes is that it is easier to reuse, both inside one program e.g. an array of sensors, or between programs.
That said, you can put (almost) all functionality of a class in in your main PDE with similar result. The only drawback is that the source file gets quite long which implies quite some scrolling as the Arduino IDE doesn't support code-folding. My biggest irritation is that scrolling takes a lot of time.
Anything bigger [than 100 lines] and there is a good chance your code is unnecessarily complex
Most of my serious applications are beyond 100 lines, largest are over 1000 lines of code - without counting the classes - but including comments. 100 is just a number, a first order of magnitude. But it is only indicative at best as you know that in C and C++ you are allowed to put all the code in one line or split it over multiple lines! So don't use Lines of code (LOC) as metric for complexity, there are far better ones:
1 count # elementary variables
2 count # compound variables (structs unions)
3 count # functions
4 count # classes used
5 count # branches (if, else, switch)
6 count # iterations.
7 count # operators (assignment, boolean etc)
finally count # lines of code LOC (there he is again)
A better indication of the programs complexity C = sum(1..7) / LOC (apply weights to 1..7 if you like)
This number indicates the complexity per line of code.
e.g. x = a * t^2; is complexer than x = y
If the complexity per line is increasing the overall complexity is increasing, but complexity is doesn't automatically mean that it is unneccessary complex.
On the other hand good analysis often results in more than one solutions for the same problem that often differ in complexity. Often people stop thinking when they find the first solution for their problem and start coding, resulting in suboptimal code. If it does the job, it is OK. But if maintaining code is also part of the job (99% of the time) everybody prefers code that is less complex if possible. The first thing todo is document code well that is adding comments that explains more than "x++, here we increase the counter x". In a second step one can optimize the code reducing its complexity akak refactoring. In a 3rd step one can redo the problem analysis to see if there are better ways to tackle the problem.
To make the circle round, OO techniques help to reduce the complexity of a program, both at design level as one can model the system on multiple abstraction levels, and on code level as it separates functionality in some logical way (OK if the design sucks ....)
my 2 cents,