Consider an obstacle like this:
The closest node to the target is #3, but the closest point to the target that lies outside the obstacle, is actually on the edge between nodes #1 and #4, so node #3 is irrelevant.
Unless you force the user to strategically place extra nodes just to account for this (which I don't want to do), you have to assume that the closest point could be in any direction, on any of the edges between two nodes - and then you'e back to explicitly listing the walls that define each polygon, which is what the previous version did.
Although the spiral method seems a little inefficient, as it's likely to require up to maybe 200 fastloop iterations (hopefully not much more than that), I would imagine that depending on the map complexity, the overall pathfinding system is probably going to use a few thousand iterations (I really ought to test that!), so the overall impact may not be that bad.