The new single-file style has some advantages. It allows and encourages you to write lots of small methods, which I think leads to better-factored code. The hassle of creating a new file, saving it, and adding it to source control (we are all using source control, right?) is minor, but added up over a couple dozen little methods is enough that it usually discourages me from factoring a class into finer-grained bits of functionality. And editing the whole of your class is convenient for browsing, search and replace, and not having to open a dozen separate editor tabs, which can then be used to organize source code for different classes.
For larger codebases, there may be performance advantages to the single-file style. Source control and deployment systems that iterate over the source tree have a per-file cost for things like stat and diff operations. For a larger codebase, say, thousands of methods, that can be significant, especially on a network drive. I suspect there's also a performance effect for apps deployed with the Matlab compiler. Startup time increases with the size of the deployed codebase. There is a per-file part of this cost, from file operations, and because the files (I think) are encrypted individually. I suspect, but have not experimentally tested, that using single file class definitions will reduce the startup cost for compiled Matlab apps.
However, I use the old multi file organization for most of my code. Partly because our codebase was started a few years back before the new style was commonly available. But partly for performance. The new single file organization only works with the new style MCOS Matlab classes, and they are slower than old style Matlab classes due to a higher method dispatch overhead. E.g. here's a benchmark snippet showing execution time of do-nothing nop() methods.
Calling each function/method 100000 times
nop() function: 0.02715 sec 0.27 usec per call
nop(obj) method: 0.24629 sec 2.46 usec per call
classdef nop(obj): 0.98572 sec 9.86 usec per call
classdef obj.nop(): 1.81307 sec 18.13 usec per call
In a codebase that makes lots of method calls, this can have a significant performance impact.
(See also Is MATLAB OOP slow or am I doing something wrong?)
One other nit is that Matlab's auto-indenter will indent every section and every method in a class definition, so the baseline of all your executable code is two tab stops in, wasting 8 columns of screen real estate.
On balance, were it not for OO performance considerations, I'd probably go with single file, and I'm writing new non performance critical classes that way.
UPDATE: It also looks like contentsrpt(), a useful documentation generator, does not work with functions defined inside the classdef file; only those in separate function files.
