It usually means they hacked in some hardware support for that one particular kernel but didn't upstream it. This is how hardware companies seem to prefer to operate. Release a product (including the drivers) and then forget about it. Maintenance is a drag and getting patches accepted upstream is too much work, plus they might come back to you and ask you to fix stuff in your code later, which isn't in the budget.

Windows bends over backwards to try to support old code. If you have something with Vista drivers there's a decent chance you can get it working in Windows 10, unless they were 32 bit only drivers. Even if you supply the source code (gasp shock! Unheard of!) you still end up chasing Kernel ABI changes from time to time.

For an example, I have an old Canon LiDE 35 scanner that I use from time to time. On Linux it just works as part of the huge SANE bundle. On Windows all I have are ancient 32 bit drivers that don't work on Windows 10, but if you download the Windows 7 x64 drivers for the LiDE 60 and hack some strings you can get it to work. A complete reversal in the amount of technical wizardry necessary to get it working over the course of about 10 years.

It seems super weird that "certification" means "works to our spec with $distros at the time of release" instead of "we have an arrangement with $company that will ensure that $distro will always be fully supported."

I agree, I moreso meant if they are on kernel 4.x or possibly an earlier version of 5.x then that could be why it's not working well

They actually managed to upstream support on kernel 5.1, but break it on kernel 5.2, and IIRC only kernel >5.5 has the fix, which ubuntu still doesn't have support for.

I expect Canonical or Lenovo or both to test all release candidates of all kernel versions after release and make sure that the hardware actually works, and if it doesn't, prevent the release of a broken Linux kernel version.

That would be the minimum level of QA acceptable for a "certified" laptop.