It isn't. Half the world already relies on ORM frameworks that barely require any input from the developer to setup relational databases, let alone knowledge on how to normalize them.
On the rare occurrences a project feels that specialization on relational database design is relevant, more often than not it's far more useful to require expertise on specific RDBMS than trivia tricks.
> If those things aren't math to you (...)
You're missing the whole point. No one is arguing that you have math formalisms. The whole point is that those formalisms do not add any value at all. Don't you understand that?
I mean, I can whip out a web app with multiple services running in the backend and with datastore using both DynamoDB and S3, and build a business around it. We can do this without ever knowing who Jack or Joe or Jim or Jose Cobb was, let alone what he wrote. What does it tell you?
I'm going to go a bit further than just not understanding, I'm actively disagreeing with you. Based on your arguments here, in a workplace I would advocate not letting you make any decisions about database schema.
Sounds like the feeling might be mutual there though. Not saying you're bad at whatever it is you do; just I want to have to have schema designed by someone who has thought deeply about schema design. Databases usually outlive all the employees assembling it, can outlive an entire organisation and getting the design right can save days to months of work.
The academics have got entire classes of bugs that they can demonstrate don't exist in normalised data, there are benefits to everyone coordinating around a standard shared view on how to lay out data and usually drifting away from the standard it turns out not to lead to real benefits long term. You can believe that is valueless or isn't math or whatever, but there is no point aggressively introducing opportunities for bugs when there is no reason for it. And to avoid doing that, the person making the decisions needs to understand the theory.
It's unfortunate that most people these days prefer unstructured blobs of json to formal relational databases. It's impossible to get up to speed in these types of environments because every time you think you "understand" the data, you find out about a random property that gets set in rare occurrences that throws off the whole relational model you intuitively built in your mind.
This also does not hold up well in an operations heavy environment. Like all things in programming, a well balanced approach is necessary. Some combination of formally structured data with some flexibility for future requirements is probably the best course of action here, but that's too much work for programmers these days.
Formalising 3rd normal form and giving it a rigorous definition so that we can test if data is properly normalised is a big deal. Ditto having algorithms in concurrent systems that we can guarantee don't have logic bugs in them.
If those things aren't math to you, then what are you willing to accept? Do you mean programmers have to sit down and draw an integral sign or it doesn't count? You're correct that doesn't happen, and you're probably setting yourself up to be steamrollered by someone who sees a well known pattern that the academics have been researching for years.
The typical corporate database has big tracts that have been "designed" by someone doesn't appear to have thought very much about how to store data in an organised fashion. It raises the question of what fuzzy thoughts go through their brain since they are only interacting with a database because they have a need to store data in an organised fashion. Hopefully their thoughtlessness doesn't matter, but doing better than that is a low bar.