A TT only matters if your device is less than the speed of the root HUB max and some other device is going faster. If both cameras are the same model, then those would not care if a bus slowed down because of a camera not being able to go as fast as the bus…but of course other devices on that root HUB could drag things down slower. The TT is indeed usually part of the USB HUB chip itself, but verification that your keyboard did not slow the cameras via “lsusb -t” proves you have the TT.
Really, odds are fairly high that there is a signal integrity issue. You can follow schematics exactly, but have rules for trace impedance cause failure for any number of reasons (e.g., D+/D- lanes are different lengths, or bend the wrong way, or are routed with unexpected coupling to a nearby trace with noise). At USB1.1 speeds you wouldn’t see this, but at USB2 speeds trace routing requirements go up substantially (and of course USB3 becomes quite a bit more of an issue relative to USB2).
Have you gone over traces to consider D+/D- routing so far as RF behavior and impedance? This would be a likely candidate if the setup works most of the time, but occasionally fails.
One other alternative is if the driver is on occasion unable to run (for example another driver wouldn’t let go of CPU0 in time)…this would block data and cause an error, but I highly doubt it would cause re-enumeration.