From the article:
More generally, the yo-yo problem can also refer to any situation where a person must keep flipping between different sources of information in order to understand a concept.
Source code is read far more often than it is written. Thus, the yo-yo problem, of having to switch between many files is a concern.
However, no, the yo-yo problem feels much more relevant when dealing with deeply interdependent modules or classes (which call back and forth between each other). Those are a special kind of nightmare to read, and is likely what the coiner of the yo-yo problem had in mind.
However - yes, avoiding too many layers of abstraction is important!
All non-trivial abstractions, to some degree, are leaky. - the Law of Leaky Abstractions.
For example, I disagree with the assumption made in mmmaaa's answer that "you don't need to yo-yo to [(visit)] the ZipCode class to understand the Address class". My experience has been that you do - at least the first few times you read the code. However, as others have noted, there are times when a
ZipCode class is appropriate.
YAGNI (Ya Ain't Gonna Need It) is a better pattern to follow to avoid Lasagna code (code with too many layers) - abstractions, such as types and classes are there to aid the programmer, and should not be used unless they are an aid.
I personally aim to "save lines of code" (and of course the related "save files/modules/classes", etc). I'm confident there are some who would apply to me the epithet of "primitive obsessed" - I find it more important to have code which is easy to reason about than to worry about labels, patterns, and anti-patterns. The correct choice of when to create a function, a module/file/class, or put a function in a common location is very situational. I aim roughly for 3-100 line functions, 80-500 line files, and "1, 2, n" for reusable library code (SLOC - not including comments or boilerplate; I typically want at least 1 additional SLOC minimum per line of mandatory boilerplate). The important point is to keep in mind and respect the limits of human cognition when writing code.
Most positive patterns have arisen from developers doing exactly that, when they needed them. It is much more important to learn how to write readable code than to try to apply patterns without the same problem to solve. Any good developer can implement the factory pattern without having seen it before in the uncommon case where it is the right fit for their problem. I have used the factory pattern, the observer pattern, and probably hundreds besides, without knowing their name (ie, is there a "variable assignment pattern"?). For a fun experiment - see how many GoF patterns are built into the JS language - I stopped counting after about 12-15 back in 2009. The Factory pattern is as simple as returning an object from a JS constructor, for example - no need for a WidgetFactory.
So - yes, sometimes
ZipCode is a good class. However, no, the yo-yo problem is not strictly relevant.