I don't like this authors approach. Always ask the question, but never add complexity because you assume you know the answer. If you have "multiple layers of indirection" that is "unused" because of paranoia that you might have to refactor your code, then you're doing it wrong. Write code such that you never have to be afraid to refactor it. That's not write code that never has to be refactored. In fact, refactor often and liberally. And if things break when you refactor, then that code is bad code. But don't add worthless layers of indirection because you write code that can't be tested, full of side effects, requiring entire components be rewritten from scratch, etc.
The top commenter says good code rarely needs to be changed. I think thats foolish. Good code is constantly changed, because its good enough it can be.
Try to produce useful interfaces and data structures, even internally. When data is stored make it easy to verify that it's in a recognized, expected, format; possibly with a version scheme that can be extended later.
Historically successful protocols often have a basic feature level and later extend it with features that are not required (at the time) but improve functionality. All the more so when users with accounts need more features than federated (not authenticated) users from other platforms.
The top commenter says good code rarely needs to be changed. I think thats foolish. Good code is constantly changed, because its good enough it can be.