With paid account it is possible to reopen a task after one solution has been submitted, so the recruiter can "give another chance" to the candidate (although we generally suggest not to), which supports the workflow you describe.
I don't think Codility checks whether one knows how to write clever algorithm. Look at tasks from ACM Collegiate Programming Competitions, they require clever algorithms. Codility deliberately focuses on very fundamental tasks. Also it does not pretend to be a final sign-off, it merely tells you which candidates to reject due to lack of rudimentary programming skills. It's not that surgeons make injections that often in their daily practice, yet I would not trust a surgeon who doesn't know how to make an injection.
Yes, it is even possible to add your own data sets, Codility will tell you what you code returns for them. I guess we should make it more apparent in the interface.
We want to avoid sticking to particular compilers/interpreters. An expert in MSVC should not be penalized only because we use GCC. Also we design the tasks so that they are compiler-agnostic (actually they are even language-agnostic). It is sometimes a bit tricky due to non-standardized type sizes (e.g. C, C++, PHP), but generally the tasks can be solved using very limited and portable subset of a language.
Codility tech team is from Warsaw University, we are more than familiar with TopCoder, ACM CPC, IOI etc. We deliberately keep Codility tasks at fundamental level. Codility is not a competition for 100 world's best programmers, it is a tool to tell decent programmers from poor ones. We can raise the bar arbitrarily high, if there is a customer who needs it.
Unless it is stated explicitly, we do not provide anything extra but the vanilla programming language and standard libraries. It is more clear for some languages (e.g. Java, C++) than other (e.g. PHP, JavaScript), but we try to stick to the reasonable canonical set of libraries.
Generally we don't want to penalize people too badly for assuming particular (but realistic) type ranges, nevertheless we think that perfect solution should be as portable as possible across different implementations of the language (e.g. one should not assume that C's int is 32 bits wide, since implementation with 16-bit int can still be Standard compliant)