I'm with Snorlax on this. Remove it by default but leave a place for a system message.

I would like to add that regexes can fail silently if a user doesn't escape slashes (/). The engine will attempt to treat the following text as a delimiter, which could have wildly unpredictable results. I had to find this out by searching our job queue logs and finding the error there. This is definitely not good, because the software tells the user that there was no issue.

That's a good point; hadn't thought of doing it the other way around. I guess this can be closed appropriately now. Appreciate the advice, thanks!

I guess that makes sense. It just isn't stated anywhere (that I could find) in the manuals that $wgDefaultSkin will override the option.
As for the hook, I would really prefer a way to just set the preference for new users, as we have multiple skins available that are still in use, and if I understand that hook, it will force any logged in user to use the skin listed. Is there really no way to set the user preference when using a default skin?

Additionally, $wgConditionalUserOptions is only available in 1.42+, and we are on the current LTS (1.39.7 (and yes, I know .8 just released; I'm testing for that update currently)). According to the $wgDefaultUserOptions manual, "skin" should be an accepted parameter, but it isn't being respected for some reason.

Okay, if it isn't supposed to create an entry in the table, that's fine, but it should still actually set the user's default skin. It does not. That fact remains.

Since this hasn't been updated yet, I want to go ahead and add this bit of discussion, as it is relevant to the problem.

Daimona's patch worked, and I was able to continue my upgrade for both of my wiki sites. I ran into this error originally while upgrading from 1.29 to 1.35, and I saw it with both sites. I would like to know if this could potentially introduce database corruption down the line, however.

Just like to note that I encountered this error while upgrading from 1.29.1 to 1.35.0, and I was able to work around it by running the maintenance script populateContentTables.php, which failed with a duplicate entry for key "PRIMARY" error but still allowed the update.php script to continue. It seems like the updater tried to work on the "slots" table before it was even populated, hence the slot not found error.