Your point basically is to isolate the host offering that specific service(s) to the outside WAN by means of DMZ so that if it becomes compromised more or less the hosts inside the LAN won't be affected. Usually true, however...
Put your mail, web and proxy servers inside a DMZ and put decent access lists on your PIX.
Put decent ACL's on them? ACL's are only as good as the person's knowledge about network security when applied to an interface manually. Pre-applied ACL's, like those found in the soho router market, seem to do decent. If you're not a good ACL writer and/or don't have the time, knowledge, or patience to append entry after entry in the lists then this is not exactly a good path to pursue.

Applying ACL's means that you have to keep up with not only net security in general but the new breed of attacks and exploits that surface every other day. A host in the DMZ could be compromised and, being isolated properly, wouldn't affect the LAN. But, the host would still be compromised. Using your own custom ACL's will also degrade performance as there is more overhead than pre-applied ones. There's pros and cons to everything.

If a host on the LAN running a service that's using port-forwarding becomes compromised the hosts inside the LAN aren't ALWAYS able to be compromised. That's a generalization that is true in some cases but not always true. That depends on the situation and the level of access granted to the rest of the LAN by the attacker's successful exploitation of that specific port-forwarded service. BOF's are pretty much worthless unless the service/application being exploited is actually running as root. This is something that can be contained even if a host inside the LAN is compromised. It doesn't just stop there and read "Yeah, we're owned... our whole LAN is compromised now!" Hosts inside the LAN can be limited in what they're allowed to access etc. You could still use port-forwarding and semi-isolate a host running a service that could potentially be compromisable from the WAN.