In ‘Programming in Scala’, following is stated:
For instance, many languages admit values that are not objects, such as the primitive values
in Java. Or they allow static fields and methods that are not members of any object. These deviations
from the pure idea of object-oriented programming look quite harmless at first, but they have an
annoying tendency to complicate things and limit scalability.
How does static methods or non-object values hamper scalability?
Certainly, there are no hard limitations, because when you need an object, but have a primitive type, you can box it, and if you need a non-static method, but have a static one, you can write a non-static bridge method.
But it is a lot easier to think about language specs or generic code if there is only one option to consider, not two.
If, for example, you read Java specs, it won’t take long before you encounter a rule that works differently for primitive values than for objects, or different for static methods than for non-static methods.
The language simplicity comes at a price, though, when you care about performance, when you write code where primitive values would have been sufficient, but the compiler doesn’t know and uses boxed values instead.
more deviations = more special cases = more dimensions to scale in
this is not about performance scaling, it is about developer productivity
“Scala” as “scalable” always meant suitable for programming “in the small” as well as “in the large.”
The promise of OOP was to offer a concept of module that enables scalability in this sense; the implication was that composition in FP was insufficient.
A simple example of the hampered scalability you ask about is the tendency to populate “utility” classes with miscellaneous methods. That harms discoverability and access control. In Scala, traits and typeclasses simplify introducing a capability to a type. Also, its regular namespace hierarchy simplifies exposing names to subclasses and subpackages.