Hexkyz for example. Src. :
http://hexkyz.blogspot.com/2018/06/chill-shills.html?m=1
It measures the execution time of some parts of the code and if the time isn't correct, the brick code gets executed.
If the next firmware update from nintendo improves the runtime of some basic parts, it could brick a lot of switches.
i doubt it counts "time" there would have been bricks already or they have set a very high threshold. Not every CPU is the same. There will be slight hardware differences making your switch maybe a little faster or slower then others.
It would be safer to count clock cycles because time spend in the debugger will create a very large latency.
Overclocking shouldn't trigger the bricking because the result wouldn't be greater then the value it is compared to...
( I don't know shit about the switch platform or how tx did code it... this opinion is assuming it works the same as i would do it on x86...).
Bricking could happen if a homebrew or Nintendo used more cycles in the boot process (maybe chainloading sx with hekate?). So yes Nintendo could maybe modify the bootprocess and intentionally brick switches using sx. This would be an evil but genius move, because tx will be blamed for it...
( again I don't know how the switch boots but I guess hen-firmware like sx and hekate use custom bootloader not related to ofw used. Thus I don't know if Nintendo could technically modify the boot process of sx causing bricks...).