You probably won't have a service that exposes only a NetNamedPipe endpoint - that doesn't make a lot of sense. But if you run your WCF service on a server, exposing service endpoints out to the world using the usual bindings, and you need e.g. a management or admin console or something like that, running on that same machine, it can make sense to use the NetNamedPipe binding since it's the fastest around.
Another possible scenario that I learned about is having an error collection service - any error or exception that happens is sent to a service to be logged. Again: that service would probably expose several types of endpoints, but if you have other services running on the same server, using NetNamedPipe binding to connect these two services makes a lot of sense.
I don't think you'll use the NetNamedPipe binding an awful lot in your WCF days - but it can definitely make sense in some cases and be quite useful in such specialized scenarios.