In most deployed configurations, you use memcache in a distributed fashion (so N machines can connect to a pool of caches), so you usually have them bind to a public interface. One that you stick behind at least one firewall.
Exposing memcached (or riak or whatever) is operational malpractice.
It's definitely dumb, but people might be lulled into thinking it isn't necessary because the trend among other servers is to essentially include their own firewalling setup, with a default of blacklist-everything that you have to explicitly override by whitelisting IPs, or by having clients authenticate. For example, you used to rely on firewalls to make sure nobody was sending spam through your internal mail relays, but these days most MTAs handle that filtering themselves, taking whitelists of "relay from here is ok" IPs in their config files, even though in theory iptables/ipfw/etc. could handle that job just fine, and more efficiently. More relevantly, most RDBMSs have a similar setup--- they won't just let any client talk to them, even when bound to a public IP.
For efficiency, though, memcached explicitly decided not to handle that kind of filtering itself, e.g. by having the memcached config file take a list of IPs of other memcached servers to talk to (defaulting to none), or including some kind of auth mechanism, and instead relies on the system firewall for that. That's a reasonable design decision, but increasingly unusual. Most servers these days see the system firewall as a backup level of defense, not the primary one, and aim to be secure even when unfirewalled.