I agree with your analysis. Developing large systems is qualitatively different from small projects.
In addition to what you mention, an important factor is that you won't know and understand all the code, and you will have to solve issues and build additions without knowing all the surrounding code.
So the code needs to have some qualities which are much more important for large systems:
- Good encapsulation, because if a change in one place can have an unexpected effect in a far away place, that means developers will either break stuff, or have to read all of that code.
- Predictable behavior, because people won't be reading the implementation.
- Clear documentation, especially in the form of types and assertions (because that's what people actually follow). If a frontend function assumes input has been sanitized, take a EscapedString instead of String.
- Bugs get more likely the larger the system grows, but they also get more expensive as 80% of the time will be analyzing context and only 20% fixing. So code should be more resilient (which is why static typing is more popular for larger systems).
These things are always good, but if it's your own project and you know all the code, it's not as important.
You can be a good developer without doing large scale development. You just probably won't be good at developing large systems.