Thresholds are often calculated by treating $X$ and $Z$ errors as occurring with the same probability. Any code that corrects one more effectively than the other will then be at a disadvantage: whichever it corrects least effectively will be the bottleneck that determines the threshold. The surface code avoids this by treating these errors in an identical way.
For fault-tolerance thresholds, the fidelity of stabilizer measurements is also taken into account. This includes errors that occur in the required entangling gates. Stabilizers that act on more qubits, and so require more entangling gates, will have less reliable measurements. But the surface code has essentially all stabilizers the same size: they all act on four qubits. And that size is relatively low. They are also quasilocal, so there is no error overhead in shunting qubits around to be measured.
The combination of these effects means that it competes well in terms of threshold, and should be moderately easy to implement.
It's true that analytic results are always worse, because they aim to establish lower bounds rather than exact values. They came more from the era when it was important to determine whether fault-tolerant quantum computation was actually possible, even in principle. Just finding a non-zero threshold was a big deal. Now we focus more on things that can be done on real devices, and how they might perform, and seek thresholds as high as we can for practical reasons.
The surface code nevertheless wins in a typical apples-to-apples comparison of numerically calculated thresholds (I'll update with a reference when I find one). But it should ne noted that the choice of noise model can be used to change the goal posts in the favour of your favourite code.
