I feel quite strongly that two local servers, which everyone else binds to, is the right way to go. NTP is designed to work that way, and it minimises the load on the public/pool servers.
I run an NTP pool server. Even in areas with well-populated pools the load is still significant (I'm running at an annualised average of 25 client requests per second, which means about 2.5 million a day). In some parts of the world, the pools are so small that the few people who run pool servers are getting quite overwhelmed.
Edit: Aaron Copley makes the excellent point that two servers will both be rejected by clients if only one of them is out-of-sync but still thinks it's correct (see, eg, this question), and that having two (instead of just one) simply doubles the single-point-of-failure.
He is absolutely right that three would be better, and in a larger production network I would agree that it is appropriate for this usage case. In my experience, however, properly-configured NTPd works a lot more often than it fails, and the risk of a single server being unavailable and client clocks getting too far out of sync to recover automatically much outweighs the risk of one server advertising a faulty time and invalidating both.
For me, two is the right number of upstream-synced servers for this network - but there is definitely a legitimate discussion to be had around the issue, and I'm grateful to Aaron for raising the point.