Some days, I feel like a guy paid to shovel shit from a slurry tank, with the entry valve full open. At least I'm left free to do it however I see fit.
That's a good start - better than a lot of folks in the IT field that receive edicts from management (or worse sales) that have little clue into the best practices, costs, or limitations of available technology.
I would be willing to bet that a lot of businesses are ran the same way you describe and it creates a lot of challenges for security personnel. That doesn't mean security is impossible (or not worth attention) nor does it mean that the business model needs to suddenly change to fit with the most secure setup possible. Finding the balance of keeping assets safe, mitigating risks, and providing users access to the resources they need is not always easy, but can be accomplished with, hopefully, few compromises.
Your questions and responses indicate that you already are on a good path and are trying to achieve that balance now. As long as you can identify your business' assets, the risks to those assets, and mitigate these risks reasonably I'd say you are on the right track. A good application layer firewall is one layer in that strategy.
Two common mistakes that my clients make with application layer firewalls are A) Not keeping them updated and B) Not sizing them appropriately. The third, fourth, and fifth mistakes relate to firewalls in general and that is C) a lot my clients will install a firewall and then put everything they possibly can behind it - This results in a slew of web servers, exchange servers, etc that are publicly accessible (thanks to intentional holes in the firewall) and are sitting on the same network segment as internal domain controllers, file servers, workstations, etc. These servers are often outdated and would be a great way to gain entry into a network. D) my clients will assume that something behind the firewall is not connected to the internet simply because they do not access the www, email, or similar application on that device. and E) my clients do not setup logging or they ignore the logs.
A is easily addressed by including the support in the total cost of ownership calculations.
B is addressed by remembering that gig ports does not mean gig performance and doing some research into the number of devices on your network, connections at any given time (state table size), and bandwidth used by these devices and then comparing these numbers against the stated performance of the firewall in question with the features you plan to use. Performance with application layer features enabled is often many times less than with only layer 3/4 firewall features enabled. Include room for spikes/peak usage, forecast error, and growth in your calculations. For example, if you see a peak of 10k connections over the course of a week, size for 50-100k.
C is generally addressed by not putting your internet facing servers behind any firewall appliance (use the OS firewall or security suites), putting them behind a separate firewall, or placing them on dedicated interfaces behind the firewall and placing restrictions on them as if they were less trusted than non-internet facing/connected devices.
D - Remember, NAT does not equal firewall and firewall does not equal NAT. Using a non-routable IP with NAT connects devices to the internet. It's the firewall that enforces policy to devices, whether NAT'd or not. The needs of each device should be assessed and firewall rules applied to the device - either individually or as a group/network segment. These rules should include both incoming and outgoing traffic (many folks implicitly trust outgoing traffic generated from devices on their network - this is an oversight, in my opinion).
E is simple. Setup logging: either via email, local syslog on the device, or remote syslog to a central server. Setup alerts. Setup graphing of bandwidth usage or device health. And then regularly review this information - say weekly - to verify healthy operation. Any abnormalities should be checked into.
Any of the commercial brands of application layer firewalls you mentioned should allow you to address the above issues.