I'm not an Apple engineer but I had noticed the watch missing from there (in my case I have a few "older" watches from previous restores, but not the "current" ones after watchOS 7 / iOS 14). In my humblest opinion that's a big part of the problem: routes are not saved because the watch is not even registered as a potential data source for that.
That shouldn't affect older routes as they're theoretically saved in Health, but I wouldn't be surprised if the upgrade just accidentally wiped those out due to some race condition or other glitch.
I still get a high CPU usage by Health.app despite the restore from backup of both iPhone 11 and Watch 4 (my health database is probably seriously broken, unlike others who got things back), resulting in the device becoming burning hot and the OS killing "healthd", the d indicating that it's a daemon (background service). With that failed and not restarted until later on, it would explain why sometimes we get gaps. The watch just pushes that data once to the phone, always expecting that it succeeds, and never tries again because it just doesn't know it failed.
At least, that's my take on it. Fingers crossed Apple sorts this out soon, because it's really frustrating. I don't care much about my routes, though the botched data does irk me. It just feels like the whole ecosystem suddenly became extremely flaky and unreliable.
If anyone wants to see if the Health background service also gets killed on their phone, go to Settings - Privacy - Analytics - Analytics Data, and search for "healthd.cpu_resource-..."). If it's there, it will probably say something like this:
Event: cpu usage
Action taken: none
CPU: 90 seconds cpu time over 139 seconds (65% cpu average), exceeding limit of 50% cpu over 180 seconds
CPU limit: 90s
Limit duration: 180s
CPU used: 90s
CPU duration: 139s
Duration: 139.01s
Duration Sampled: 137.67s
Steps: 174