The logic is simple. Suppose that a fast programmer can do some task in time t. We have a slow programmer who programs twice as slowly. In the worst case all of time t spent by the fast programmer was spent programming which is what the slow guy is slow at. In that case our slow programmer will take 2t, a linear amount of time. If the slow programmer had an alternative strategy he would only use it if it reduced the time to complete the task. Therefore the time is linear at worst.
Note that even if the slow guy is 1000 times slower it's still linear.
Please explain why the logic isn't right. Could it be that the logic is right but that slow programmers tend to do things on paper first, which is not the best strategy?
Because slow programmers don't program first. They program last, and do "big design up front" on paper. This is because the cost of a bad idea is hours wasted, and despite the logical coherence of various "expected value" arguments, students are loathe to risk having wasted multiple hours doing the wrong thing. Because humans' internal risk functions and utility evaluation functions are not linear and bayesian, people who code slowly also code differently, and those differences further slow them down with the goal of having less wasted time. In an effort to reduce their variance, they unknowingly increase their time-to-solution.