I think you are correct if the httpd user has more rights than the dev should have.
Also when I have my rules and the dev doesn't want to hear them, I just pass the work to the next guy in the row.
The risks:
- They need shell access to your machines
- They need access to the httpd user (they can control your webservers basically)
Any of the above means they can mess around with stuff they shouldn't be messing about with. Apart from that they can configure your webserver to ONLY work with their scripts, meaning that if you ever break contract with them, you will be in a lot of hurt to get this fixed. (This is a possibility, not saying they will)
If you allow them shell access I advice you to, by contract(!), draw out what they can touch and what they can't. (talk softly with a big stick)
Like you are saying, if their scripts should only be writing to a certain dir, then there is definitely no need to give them anything else than a shell that can write into the webfolder. If they need access to certain configuration files, you can add them to the httpd group. If they need access to restart a webserver, you just give them sudo for the restart command.
Never give anyone more clearance than they need to get the job done. If marketing persists you outline very carefully what can happen if these devs fail and create downtime and how this can affect company image. Make sure you cover yourself as well.
EDIT
They want to run their own access scripts as a httpd user so they can have full write access with a browser?
This is not really a good idea, if that thing gets breached you are in for a lot of hurt.
The best thing I can come up with at the moment is this nist guide: http://csrc.nist.gov/publications/nistpubs/800-44-ver2/SP800-44v2.pdf (check chapter 5.2)
an article by searchsecurity on why you should use a dev server:
http://searchsecurity.techtarget.com/tip/Six-steps-to-securing-your-Web-server