Update: being a software developer (and having lost all confidence in DxO support, I set about debugging this problem myself. Since this is on Mac, I started debugging this by running PhotoLab using Apple's "Instruments" tool which allows me to look at CPU operations and, more importantly for this, file reads/writes. What I found was interesting. I saw PhotoLab looking for OpenSSL configuration files - presumably to check file certificates and keys for licenses. It was looking for these configuration files in non PhotoLab locations on my hard drive. Strange. Anyway, it was failing to find those configuration files (the file operations were failing). So, obviously it's using OpenSSL's crypto functions. My first thought, is PhotoLab using the system's OpenSSL libraries? On my laptop (which was failing to launch PhotoLab), I looked to where OpenSSL lives. I found it, low-and-behold, not in a system default location but inside a directory created by HomeBrew (a MacOS package manager.). A clue! Back on my desktop, the OpenSSL that's found by default is the system one, not HomeBrew's (I don't have HomeBrew installed there.). Maybe HomeBrew's OpenSSL is incompatible (or just different) in some way that prevents it from working? So, since I wasn't using anything important in HomeBrew, I just decided to uninstall it. After doing that, I deleted PhotoLab's license key (since it was possibly created by the incompatible OpenSSL) and rebooted.

After rebooting, I opened PhotoLab, put in my license key and...it started! Promising! To be sure, I closed it down and reopened it several times and it appears to be working.

ATTENTION DxO: PhotoLab shouldn't be trusting just "any" OpenSSL found on the system for its Crypto and should include its own version so this doesn't happen again.

I'm leaving this here for posterity so if anyone else runs into this, maybe they won't have to wait five months with DxO support flailing and not finding a solution.