The rest of the puzzles get pretty interesting, I shouldn't have just stopped on the first and spent all the time optimizing it.
If the author sees this thread it would be fun if you could disturb the dynamics with the mouse after completing one. I wanna watch the ball catching piston right the ball if I poke it.
I just spent too much time messing around with this, so here's the results. The simulation has a limit on the maximum magnitude of the force of your controller, which in this example is 50. The system is described by x'' = -1.00204*x + u (by experimenting with console.log). The theoretical solution to minimize time to the origin on a system like this is a bang-bang strategy: go full actuation and at some point slam the breaks to stop exactly at the origin. Using this strategy you can calculate that you should hit the brakes(-50) starting at x= − 0.867, with the system arriving at the origin at t=0.403. But the timestep of the simulation is dt =0.02, so the system goes from x=-0.874060101875918 to x = -0.6686069466721608 in one timestep, missing the critical switching point. If you try to switch at -0.6686069466721608 it overshoots and at -0.874060101875918 its almost there when t = 0.4 but not good enough for the simulation to decide you finished the challenge. So 0.42 has to be the best you can do.
What you controller actually does, due to the actuation limits, is almost the strategy described above, staying either at 50 or -50, except for 3 time points, which make the dynamics just right to land on the origin.
There is a mistake in my first comment, the system is described by x'' = -1.00204*x' + u , I forgot a '. Also in the second example , where there is no x' term, you can reach the origin in 0.4 using this strategy.
