Personally I don't like "do this task to prove what you can" kind of interviews and we don't normally use them ourself. I believe we have used it once or twice in the past, but each time I made it clear to the interview object, that if they did not get the job we would compensate them with $X for their time. At least if its done that way it is tasteful imo.
What I see as the problem with using these kinds of tasks in the interview procedure, is that the person that is leading the interview does not know enough about the field to know if the interview object really know what they are talking about, or just pulling up fancy words.
However the problem is also that unless you have a third party reviewing the code they make, you still does not know if it is optimal. You would just know if it works or if it does not work.
If we take your example project, if it is created properly, you can add/remove suppliers by just dropping in/removing their class module. On the other side it can also be made as an intermingled mess.
If I was to ask the interview object to do something in this task, I would ask them to setup the UML for the project (class and activity diagram), as that is all you need to judge if they are planning the development and integration correctly. Of course this does not show their PHP/MySQL skills, but it show their application development skills. And that is what most "PHP hackers" are missing, and the second they know that they can start calling themselves "developers".