I'd like to underscore the previous post. This is the reason that every argument I've seen on this page in favor of squares over hexes (with the sole exception of "I like using right angles") is completely bogus, and that includes Frogboy's own. If we were actually talking about squares, they'd all be valid, but we're not. If diagonals are treated the same as orthagonals, every argument against hexes can be made more strongly against squares.
Square-root-of-two math on movement costs would fix some of the distance issues, but it still doesn't change the fact that I can make lines in two orientations on a square map which fully blockade passing units and expose only one face of each member of the blockade; whereas on a hex map I can do the same in three orientations. Furthermore, try drawing a circle (defined by boundary squares being equidistant in terms of movement points) on a free-diagonal square map, and then try it on a hex and tell me again which one simulates distances better. It's not what we're used to aesthetically, and yeah, it's a little harder to code; but it's the better method for this genre... unless some additional mechanics are brought into play.
Now, I know the investment in squares is pretty heavy now. Most of it could be retooled without as much effort as it seems, but the world generation code would be tough. So maybe something else can be done? Again, proper movement calculation for diagonals would be huge, and since movement points are already floating-point it's probably feasible. (That whole thing where 0.1 remaining movement can get you into a tile that costs 2 is probably counter-productive, though.) The other necessity would be diagonal interception, essentially removing the free diagonals if they are adjacent to a blocking unit or tile:
If you could do this, along with diagonal distance correction, I don't think I'd be so damn frustrated with squares.