It's distractingly hot and humid here, and I'm not exactly an expert, so I hope this post makes sense.
You may want to try your tests across several different pairs of diagonal and orthogonal directions over multiple tests for each set of length and direction combinations. If two goals are judged to be identically distant the algorithm might take whichever goal was created more recently or some other hidden tiebreaking factor that might mess with the data. It's also possible the game might prefer certain directions over others if they're identical distances; dwarves do have annoying positioning preferences for construction, after all.
Vattic's modded goblin idea might simplify the secret tiebreaker issue since they (probably) only want to reach the map edge, though my guess is it's better to increase the number of tests instead of timing multiple pathfinding agents simultaneously. If you have the patience, you could do any of these tests frame by frame to figure out if diagonal movement speed is different, as well as if the pathing cost is different.
It might also be the case that object finding is implemented by a different algorithm from that of path finding. The object finder might evaluate the apparently Euclidean distance of every object to the dwarf to find the closest object the Pythagorean way (the squares-are-squares hypothesis), while the path finder might use a simple version of Manhattan pathing which considers diagonals to cost 1.0 dwarf-efforts instead of ~1.4 (the squares-are-circles hypothesis). That would be a very... interesting... design decision, but to my novice understanding, it's plausible that object finding algorithm would be faster than using the terrain-sensitive pathing algorithm, since the latter needs to be 100% obedient to terrain restrictions.