"So do you think it's really a case of regular everyday programmers not being better because they don't know math?"

Causation is a strong claim, and I lack the evidence to back it up.

For an application programmer moving things in and out of databases, here's an example of the sort of thing you are dealing with all the time and may not realize how deeply mathematical it all is:

1. There exists a set of Operations on the database.
2. Each Operation has some characteristics:
a. Atomic
b. Consistent
c. Isolated
d. Durable
and each of those statements itself carries mathematical content (for
instance, almost all databases ship with ways of choosing what
Isolation means).
3. Operations may be composed into Transactions, which depending on how
they are manipulated may or may not violate the properties of the
isolation itself.
4. For each such Transaction, it may either Succeed, Fail, or do something
probably-horrifying in between.

As you go to use the database, you need to understand these properties, how they work together, how to harness them best in your code and how to deal with when they break down (for instance, migrations often break transactions). As you write code that ties together database operations, you're doing mathematical work composing together various atomic operations to obtain the result you want. This is particularly obvious if you've ever written code that manages transactions yourself, but has to involve other various client-code function calls within the transaction; you rapidly get into the world of "recursive transactions" in one form or another.

How do we recognize a "mathematical" API? A more "mathematical" database will work to minimize the "do something probably-horrifying in between" cases. More of the compositions will be legal without breaking the Transaction promise, i.e., perhaps you will be able to roll back a schema change. The properties will be clearly spelled out for each operation, and the transaction will do a better job of maintaining them. Care will be taken to ensure that any data conversions are as "isomorphic" (for now, read "reversible") as possible, and will generally refuse to "guess" what something means.

By contrast, a less mathematical database will contain more operations that break the guarantees. The documentation of what properties are maintained by which operation will be lacking. Transactions will frequently be broken because it's "no big deal in practice". Data that doesn't fit the hole it is being put into will just be hit with a hammer until it fits, and you will not necessarily be able to figure out what it started as. ("This date is 0000-00-00... where did that come from?" three days later "Oh, crap, I inserted someone's name as their birthdate...")

Basically, PostgreSQL vs. MySQL, to put names on these two styles, especially older-school MySQL... because, you see, over the years MySQL has been forced to get more mathematical, because otherwise it loses data and is generally a pain to work with. PostgreSQL's heritage is far more "mathematical" than MySQL, and it manifests in a better product.

If this just sounds like "good API design", well, yeah, good API design encompasses having a strong mathematical focus, but being "mathematically-aware" code goes beyond that.

Few programmers really know math, but even fewer really get how to translate that into practical code. It's a hard discipline to learn.