Ok... I just did some extensive testing using Brent's code both as is and with some mods to give the test table a bit more bulk.
Using a MAXDOP of 1, like Brent did, the 2019 Compatibility Level ran using about 38% LESS CPU and Duration than 2016. (In other words, 2019 was FASTER)
Using a MAXDOP of 4, like my normal setup, the 2019 Compatibility Level ran using about 46% LESS CPU and Duration than 2016. (In other words, 2019 was FASTER)
My thought was, "What am I doing differently because both of those sets of tests indicate that 2019 isn't a problem with performance?"
... And then I reread the Brent's article and finally saw the "parenthetical fine print"...
(In this demo case, 2019 compat level actually works beautifully, dropping the CPU time down by about 1/3, and I wish the client’s case was that easy. They already tried that before they called me. Bummer.)
Maybe I'm missing something obvious but... IMHO, that strongly suggests that the real problem is actually "just" a yet-to-be-discovered problem in the actual client implementation (including but not limited to Windows or 3rd party software installed) or hardware or ??? and NOT an inherent problem with 2019.
I also did the same testing in the 2022 (160) Compatibility Level with similar results.
The good part of all this is that, much like the little girl on the "6th Sense" said after her gut wrenching expulsion of stomach fluids, "I feel much better now" about the impending migration from 2016 to 2022 that we're going to make in the next few months.
From Steve's Article:
"...you might document some queries (in addition to Brent's) and record the results. That might help you decide when you upgrade."
Well said... That's one of the many reasons why "Baselining" is so very important (and not just for SQL Server version upgrades).