You are just testing willingness to jump through hoops in order to get the job (and, hopefully, to keep it). Which could be all that is needed for a megacorp job. In a workplace where you are very likely have more than enough brainpower to solve any problem just because of its size, teamwork and loyalty are much more important than expertise.
In a smaller company this is not true though. If you only have 10 engineers there is a good chance that none of them is qualified enough to solve the current problem so even if they all are extremely loyal and cooperative - the problem will remain unsolved. Even with a 100 you might end with just ~10 experts who are going to be overextended, burn out and quit. So, while loyalty and teamwork are still important, you really, really want to test for the actual expertise in a small-medium company. Unless you don't foresee any hard problems, then hiring for loyalty is the best you can do.
In a workplace where you are very likely have more than enough brainpower to solve any problem just because of its size
Except that a company that's 10 times as big is working on 10 times as many things. The idea that a huge company can afford to hire just anyone because they're so huge and they only need a few smart people is ludicrous. If that were the case, these companies wouldn't feel the need to pay so much.
It does not matter as long as 99.9% of those things are a mix of busywork and trivial problems.
The scenario I have in mind is something like this: you make an app, your team manages UI, backend, whatever, just fine - it's simple and is 99% of the job. You release your app and a million people download it, next day you are flooded with crash reports, it crashes for 25% of the users!
Megacorp: calls a special team of greybeards who spend 24 hours digging and find it's a bug in a driver for some popular chipset. They write a fix in another hour, file a bug with the popular chipset manufacturer and return back to playing WoW.
Small business: panic, panic some more, post questions on stackoverflow, really panic, find a bogus solution, release a patch in a week which makes the app crash even more because it's rushed and is actually breaking things by design, go back to panicking. The app gets bad rep, even people who had no problems are dropping it, its reputation is destroyed. The small business tries to pivot and shuts down in 6 months.
Problems like this do not happen often but when they happen it may end the business so you don't need a lot of resources to solve them but if you have 0 then you are not going to last.
Except the problem didn't happen after the bug was revealed. The problem happened before, during development. Better engineering, better development practices, better engineers, is what you need to avoid problems like that.
And you don't get better engineers by hiring just anyone who comes along.
Yes, better engineers would have caught it before release, maybe. This is why I am saying that testing for loyalty makes no sense for smaller companies as a loyal engineer may not be any good. I can even speculate that the best engineers are unlikely to be very loyal e.g. I doubt Google makes its "stars" to jump through the hoops.
In a smaller company this is not true though. If you only have 10 engineers there is a good chance that none of them is qualified enough to solve the current problem so even if they all are extremely loyal and cooperative - the problem will remain unsolved. Even with a 100 you might end with just ~10 experts who are going to be overextended, burn out and quit. So, while loyalty and teamwork are still important, you really, really want to test for the actual expertise in a small-medium company. Unless you don't foresee any hard problems, then hiring for loyalty is the best you can do.