The catch-22, of course, is that at some point, MySQL was the "new thing" to Diane, so how did she learn it in the first place?
The answer of course is that judgement is less about making decisions upon familiarity per se and more about knowing when unfamiliar technology seems to provide good trade offs given what is known about it. For example, PostgreSQL may be unfamiliar, but choosing it is a wildly different type of decision than choosing another less mature unfamiliar data store, since at a high level PostgreSQL is known to be a well-understood, mature technology that may provide significant leverage over MySQL in certain scenarios. Being able to understand the various dimensions of technology choices and make good ones with limited information and experience is what makes good judgement, not just an outright aversion to unfamiliar things.
2nd dimension: ecosystem of the tool (developers/libraries/support/etc)
3rd dimension: developer's ability to use the tool (time to learn, current ability, etc)
If you think on factors going from 0 to 10, MySql could be [4, 7, 8] and Postgres could be [7, 7, 4] for that developer.
Of course the 3rd factor depends on the developer (and on the time available), for example I know Go is very powerful, but I wouldn't use it, unless the available options for me are not good enough for a given problem (so the time to learn compensates for the loss that using other technologies would incur)
I think another important dimension is the suitability of the tool to the technical culture and composition of the organization. For example statically typed java-ish languages tend to be more attractive if you have many disconnected groups contributing to a code base, and if I'm being cynical, overall less average skilled programmers just hacking out features. Whereas a small team of top-tier developers are more well positioned to leverage the benefits of more fancy tools and languages.
Diane most likely chose MySQL because it was the most popular open-source database. Popularity is often reason enough to choose a particular tool, because it means that that tool is more likely to be supported by other good tools.
"Popularity is often reason enough to choose a particular tool"
Widely available, many eyes searching for (and patching) security bugs, many people can understand and debug it, probably the most documentation out there, its the simplest possible overall way to do it, she's not exactly doing anything new, so using a tried and true successful solution is good business and sound engineering practice.
So, the cub scouts are building birdhouses this year, again. Last year we used hammers. I found a nailgun recently invented in the black forest region of Germany which shoots a special birdhouse domain-specific-nail thats a precise metric size specialized for this kind of wood and building birdhouses, unlike local nailguns which use an air compressor or .22 blanks, this one uses compressed unicorn gas, which everyone who's cool knows it doesn't smell, and its brand new and I'm the only guy this side of the pond who knows anything about this new nailgun and the only guy who can use it or maintain it, and it cuts hammering time down from 5 minutes per birdhouse to 5 milliseconds even though theres no business case to care. Oh no wait I'll just bring some hammers again this year. But old fashioned obsolete hammers don't scale to 10B units! Oh that's OK the school gym where we have pack meetings only holds 500 and usually only about 20 scouts show up anyway and the countries population is only 400M, so I'm all good. And given other business constraints the scout pack is permanently constrained to grow slower than I can buy more hammers. Yeah, looks like a job for a hammer, its hammer time... Would I roof a house with a hammer, well no, but I'm not roofing a house so I don't much care.
Personally, as a dev, I push myself a little with each new project. I've been using Sinatra for all my web projects, with this latest one I took the jump to Rails. Otherwise the project fell squarely within my realm of knowledge, as a previous project showed me how the Facebook API works.
The time before that I tried to incorporate good OO style.
Next time I think I want to incorporate testing. Or maybe I won't feel that the next one is the right time to incorporate it, and instead I'll pick up a new Javascript library.
As devs, we have a remarkable ability to shape a project by choosing which technologies to use. So long as we exercise good judgment, we can learn new things on the job and not have to bet the farm.
As for MySQL / PostgreSQL, that decision probably didn't matter all that much for the given problem. Abstracted over with Sequel, they're pretty much interchangeable until you get to heavy, industrial-scale use. A lot of people can go an entire career without needing to figure out the use case for each.
I think that asking why a programmer knows any piece of knowledge is a very good glimpse into how competent she is. I don't care that somebody likes Git more than SVN but I do care why (on a technical level) somebody likes Git more than SVN.
The answer of course is that judgement is less about making decisions upon familiarity per se and more about knowing when unfamiliar technology seems to provide good trade offs given what is known about it. For example, PostgreSQL may be unfamiliar, but choosing it is a wildly different type of decision than choosing another less mature unfamiliar data store, since at a high level PostgreSQL is known to be a well-understood, mature technology that may provide significant leverage over MySQL in certain scenarios. Being able to understand the various dimensions of technology choices and make good ones with limited information and experience is what makes good judgement, not just an outright aversion to unfamiliar things.