The best tool for solving these problems is a whiteboard; writing code should be seen as a last resort, and brute-force solutions should be shunned, as they provide no insight.
That's what happens when time-to-solution is what you optimize for. I'm sure it's familiar to startup programmers :).
But many problems cannot be solved using brute force. They will give you one problem that can be solved using brute force, then in a later problem they increase some n to the point where it cannot be solved using brute force. So it forces you to find a better solution.
For a lot of problems, especially in early stage startups, the brute force solution is more than sufficient and avoids premature optimization. Having perfect algorithms for everything comes with an opportunity cost in startup land that isn't aligned with whether or not your business succeeds most of the time.
(This really only applies when the efficient implementation doesn't already exist in the standard library or a package.)
Most of the elegant solutions do exist in libraries out there, but the point is to pass down the underlying knowledge.
I don't think it's really fair to liken something like mathematics to the startup world, something that has all sorts of nondeterministic factors involved.
So project Euler does not always steer you simply to a correct answer, they also want you to achieve that answer in a particular way.