More is more complex.
Having more lines of code, methods, classes, packages, executables, libraries etc. always means also to have more complexity (which is bad). An ideal number can be around seven, which means:
Of course this is not possible in a realistically-sized software system. So more realistic values can be debated. Seven parameters to a method is quite much and can be regarded way too many. On the other hand seven methods per class and seven classes per subsystems are usually too few. Also seven lines of code per method is sometimes not realistically achievable.
This means that given the complexity of the problem is fixed, a suitable compromise for the number of methods, classes, etc. has to be found. Reducing the number of statements per method typically results in the introduction of further methods. Reducing the number of methods per class can be achieved by dividing the class into several smaller classes, etc.
Furthermore it is actually not the number of lines, methods, classes, etc. that is relevant but the effective number of items that have to be kept in mind. So reducing the number of lines by placing several statements in one line does not help. Neither the introduction of an additional obvious private method exceeding the limit will do any harm. MIMC is just a rule of thumb stating that the introduction of further modules (and the like) usually has a higher complexity as a drawback.
The human brain can only handle a relatively small amount of “items” or “chunks” of information efficiently in the short-time memory. This cognitive limit is commonly referred to as being “seven plus or minus two” items 1).
While the human short-term memory is far more complex than can be expressed in a catchphrase like “7±2”, it is certainly true that it is somehow limited. For the validity of the MIMC principle the actual number of items is as irrelevant as the precise inner-workings of the human mind. Short-term memory is undoubtedly limited and exceeding this limit will impose a much higher effort for understanding. This has a negative effect on maintainability and defect introduction.
Note that many principles are contrary to MIMC as they favor the introduction of additional modules. This means that it is worthwhile to consider MIMC when considering one of those. Nevertheless this does not mean that this is true the other way around. When considering MIMC, one wouldn't want to consider all principles that have complexity as a disadvantage. So here are those needing consideration: