I think you imagine wrong.
> I've never worked on a team that didn't carefully consider their schema from both a performance and extendability perspective.
Count yourself very lucky.
Students still care and should have learned these principles in uni. They tend to overengineer and focus too much on the technical challenges
In bigger companies, most IT people tend to be people who got the job because they started coding back in the day when you could get by using just common sense and gut feeling. Today we know those often lead to dark patterns and bad database design, but those people have now grown into architecture and management positions and have no clue what they are talking about.
This is very prevalent in tech teams of non tech companies (e.g. manufacturing, banking, healthcare, CPGs,...)
Glad to hear you've been part of well functioning competent teams of professionals. I know they exist - I've been there a couple times myself over the years, but it's not a given. I would probably say it's not even the norm if you include a wider range of places where tech/developer folks may be employed.
A 'team lead' role is filled by someone who is dating the department manager's family member? Seen that happen.
"Joe's been here longer, so he gets to make the final decision on things". OK, but Joe graduated high school last year, and he's cutting in to systems built by people with 20+ years of experience (both in software and in this domain), and Joe is replacing it with some cut/paste stuff he found on stackoverflow last week.
I was going to produce a larger litany of dumb scenarios I've had to wrestle with, in painful detail, but unsure that would do much to convince you of anything. (venting does help me occasionally, but won't ATM).