Having a dedicated test image (like /recovery) is a possibility, but it wouldn't be the same environment as the user. The kernel may be different, maybe some runtime calibration data would be missing, and most customers want to see their phone working after a repair.
Having a builtin validating code as one commenter mentioned would be a godsend, but nearly all companies do everything they can to make customers not want their phones repaired.
[1] things like some sensors not working, accidentally clipping the tape with buttons, touch screen being funky (although that likely was due to non genuine screen), or my favorite - gps working but never able to get exact location)
Phones also have induction chargers on their back plates (Qi, usually to charge heaphones and stuff), that have to be enabled in software to charge.
Diagnosis software is built into iPhone so I can put a trust on it that it ain't sharing private data to the store employees.
Similarly they ran a diagnosis again at the end of repair. They did boot up the phone my themselves and ran it. Looks like they can run diagnosis on locked Phone.
This is overall much better than asking to unlock Phone.
If there was some kind of "status debug port" or whatever, the technicians could've done the various checks the sibling talks about without needing full control of my phone.
This is how my repair went through. At no point they asked for my passcode or to unlock Phone.