Both clocks are counters. A power-on-hours value in the SSD's firmware reaches a number the code cannot handle, 32,768 being the point at which a signed 16-bit integer overflows, and the firmware asserts and stops. Dell's engineering note for the 40,000-hour case describes an assert with a bad check on a circular buffer's index. Whatever the mechanism, the effect is the same: the controller inside the SSD halts, the drive stops answering the host or answers with 0 GB and a medium-format-corrupted sense code, and it does not come back on power cycle because the counter is still over the limit.
The vendors' advice was to update firmware before the hour arrived, and the updates work. After the hour, HPE's position was that the SSD and the data are unrecoverable. On the bench it is more particular than that. Some of the failed drives answer at controller level, with the NAND intact behind a halted firmware, and can be imaged with the right tools for the model; some have a controller that will not address its NAND again, and there is nothing to read. Which is which depends on the model and the failure mode, and the first look tells you at no charge.
The set is the other half of the story. A RAID 5 of six SSDs fitted together loses four in an hour and is offline; if two of the four answer on the bench, the set can be reassembled from six images; if none do, it cannot. What decides the outcome is often what was done in the hour after: firmware updates pushed onto the failed drives, a rebuild started onto survivors about to fail, the failed drives re-added to see. None of those helps, and each can turn a partial recovery into none.