In my entire career (35 years), "foundational knowledge" has been important... maybe twice? Maybe once? Guessing, because I don't actually remember any instances.

(I need to back away from that a bit, because you mentioned SOLID. That's important. The rule of 3 (now 5) is important. I didn't regard them as foundational, though, because I started in 1985, and SOLID wasn't really a thing then, and the rule of 3 wasn't part of the foundations then. Back then, it was big O and structured design. I would agree that now, SOLID is part of the foundations. I didn't learn it that way, though. I learned it 10 or 15 years into my career. And no, that didn't lead me to making messes earlier, because we weren't in an environment where it mattered.)

But even not knowing SOLID won't lead you to making big messes in the kind of environment I was talking about. (It may lead you into little messes.) The big messes come from designing an API badly, naming it badly, creating something that fits badly with the rest of the code base, changing things that you think need changed without understanding what impact that has on all the code that uses it, and so on. Mistakes from SOLID, in contrast, tend to be fairly localized to one module.

Disclaimer: I don't actually have a CS degree. You may regard that as justification for ignoring my opinion on this topic. But I've seen some fresh CS degrees over the years, and I stand by my statement that they aren't very prepared for being software engineers.

Proper API design is software engineering, not computer science. And it does come with experience, but it's not necessary to start from zero.

Schools are coming around to the necessity of software engineering principles, and they're including an awful lot of solid software engineering content in their CS programs even at the undergraduate level nowadays.