The router passes the NAT'd packet along its default route because it has no particular idea where the Google server is.
Once the packet gets to the ISP's customer edge router, routers keep passing the packet along their default route until it encounters a core router that has some specific idea where that Google server is.
Once it reaches that core router, the packet will match an aggregate route that your ISP learned from one of Google's border routers (using a protocol called BGP). It will then follow the route to get to the ISP router that connects to Google's border router.
ISPs typically try to get outbound packets to the destination network by the shortest path, a method called "nearest exit". The logic is that your ISP doesn't know Google's network as well as Google does, so it's most efficient to get the packet to Google as quickly as possible. So if the packet is going across the country, it will typically be the destination network that does the long haul segment.
Once the packet gets to Google's border router, the process goes in reverse. Google's border routers have a good view of Google's internal network and can typically find the shortest path to the destination local network (typically using a protocol called OSPF). Once their, the edge router for that local network puts the packet on the wire for the destination machine which receives it.
This assumes your ISP and Google peer directly with each other and the destination machine is on a network operated by Google. These things are not always the case.