That's insane. If something is wrong they will not know if it's a problem with the ASIC or not. They can't complain to the ASIC vendor either and they will not have a clue in terms of yield. Did they do this to save time so they would not have to learn and run ATPG tools?
What are you talking about? What would be an example defect that would completely disable a chip with 4 non-overlapping/non-intersecting clock trees?
Please go back to your ATPG tools and obtain the probabilities. Then report back here and re-state who is insane.
Also: use your best design-for-test methodology to create a test pattern. Then compare the coverage with just any 10 random 80-byte test patterns. Then come back here and report who is a CAD-monkey in this thread.
Edit: I'll add this explanation for the readers unfamiliar with logic design. SHA-256 is essentially self testing: there's no internal state that is either not controllable or not observable. Same with all the interconnects. It is possible to construct a very-low-probability faults that will go undetected in the unrolled design. But their probability is
way lower than the acceptable hardware error nonce rate in a Bitcoin miner (single percentage points).
For the readers unfamiliar with logic design but capable of compiling a program: take an example working SHA-256 code and make a single character change somewhere in the code, e.g. '0' to '1'. Then recompile and compare the results of hashing a test file with 1000 randomly choosen 80-byte strings. You'll immediately understand what it means "high toggle rate" and "self-testing logic".
This self-testing property has been discussed on this forum multiple times, in English and in other languages.