There are plenty of things in what you wrote. For example, My assignment was to build a command line app. The spec given said nothing about how bad inputs should be handled. How should they be handled? No Op? Throw exception? Friendly error messages? How?
Note how the evaluation changes from one person to other, you could be someone who expects an exception to be printed, I could be someone who expects an exception to be the wrong way, and would rather prefer a No Op.
As you yourself mentioned, SQL injection validations are important to you. Think of it from a candidate's perspective, you gave them a project with a certain set of features to finish in a deadline, and they need to finish it while holding a full time job. The candidate does the best they can to finish all the features. But you seem to have an invisible/opaque measurement in the form of SQL injection validation. The candidate might think you measure in terms of feature completion(Which would be correct, the project needs to work to be considered finished). The candidate could implement your spec 100% and yet get rejected.
>>it has some semblance of unit/automated tests, API validation, error handling, database migrations, good naming, and the code isn't all jammed in to one or two files.
In 24 hours?
What are you hiring for really? And why that kind of tearing hurry?
Having people to finish this kind of a high intensity ultramarathon coding drill under a crippling deadline. And then expect them to not just finish the assignment but also comply to your invisible quality checklist which no one knows but you.
For a change try taking such tests yourself. Like biggish projects, under super tough time limitations, and while you are at your current day job, with all the quality checklist evaluations attached. And then have it reviewed by other programmers.
You will see everyone has their own evaluation methods, and big feature projects delivered under heroic efforts, with tough deadlines tend to force you into some or the other quality compromise.