When talking about DNS servers, it is important to distinguish between recursive resolvers (those servers providing clients with name resolution services) and authoritative nameservers (those servers answering final queries from local zone files).
If you are talking about recursive resolvers (DNS caching servers), then, by all means, if an organization has an intranet, the recursive resolvers should be there, not on the Internet. And if the organization does not have a segregated Intranet or internal network, recursive resolvers that permit queries from a restricted set of sources are certainly a good idea. As you say, an ISP might have a case for a wide open resolver, partly because queries for non-public names aren't expected to be handled by such a server, partly because of the trouble of listing very large amounts of permitted IP addresses, and partly for historical reasons (it's the way it was always done in the past).
If you are talking about authoritative nameservers, then one good reason to have those servers out on the Internet is for excellent response time. Every single client who wants to reach your website, your email server, your SIP server, or pretty much anything else you can think of to offer by name under your domain name is sooner or later going to generate a query against your authoritative nameserver (except if the answer has already been cached). The response time of this server is going to impact the response time of every service you offer. You want that query to go to a responsive server in a well-connected hosting centre, if possible. If you don't have servers of your own in such places, outsourcing authoritative nameservice to a DNS provider is probably a good idea. These days, almost every domain registrar also offers outsourced authoritative nameservice if you want it. I exaggerate a little bit the importance of a very responsive authoritative nameserver, but you get the message.
Still on the topic of authoritative nameservers, I should note that at least one of the threats you mention, cache poisoning, is not applicable: an authoritative nameserver is configure to not answer queries from cache. As for amplification attacks (where spoofed packets are sent with a question, the answer is larger than the question, and this answer gets directed at a victim), the location of the nameserver (behind a firewall or not) isn't going to make a difference. To some extent the nameserver has to answer those queries no matter what or else client's aren't going to find the services under your domain.
A common configuration for organizations with intranets is split DNS: there are two sets of authoritative DNS servers. One set has the public version of the zone, and it belongs out on the Internet. The other set has the internal version (which probably has a superset of the contents of the public version) and belongs on the intranet. This case is pretty simple. The public authoritative servers are unable to accidentally leak any private DNS information because they don't have a copy of the internal zone file and they can't get one since they are out on the Internet. (Obviously this assumes your zone file deployment process won't ship an unsanitized zone file out to the public version of the server during an update!)