And for most code where the speed actually matters, the code is sufficiently complicated that you'll never really know whether it's truly as fast as it could possibly be.
I once took a personality test (I tried to game it, but I didn't). The results classified me as a heavy "maximizer". Just in case I didn't already understand what that meant, this post is a great reminder.
The point is that no program can be "perfect" in the most philosophical sense -- that of having no flaw. In the eyes of an OCaml programmer, lack of OCaml bindings certainly would be a flaw.
The point is that the last two questions are the ones that truly matter.
There are many ways to be imperfect, because there are many ways to be disordered (higher entropy). There is only one way to be perfectly ordered.
My point is that, in practice, counting the ways of perfection is counting the ways of imperfection. This focus on all the things lacking is discouraging and distracting from whatever you are actually trying to do.
IMHO, it's more effective to focus on what you value, what is worthwhile, and keep improving towards that; that is, to go towards what you value, instead of away from imperfection. It's more fun and you're more likely to come up with something that will be valuable to others - instead of "perfect" within some impoverished universe.
I say "impoverished", because the only way to have perfection is to define it, and as soon as you define it, you exclude all those possibilities that were beyond your imagination until you stumbled upon them, often via a "mistake". i.e. Any defined universe is necessarily impoverished, compared to the big one.
If I'm writing a 100-line python script to process a text file, I'm not going to worry too much about making it run as quickly as possible, say.