As with any tools, I would say it's got more to do with how you use them then whether or not you use them.
Personally, I like to have all of my business logic and non-view decisions figured out before I forward to the JSP and then use JSTL and EL for help building up the markup only.
With that line of thinking, I can't picture myself using, cookie, header or headerValues in a JSP. A case may come up but, usually, if I'm reading headers, it's because I want to branch on them and make the app behave differently according to their values or because I'm logging something like a referrer header. Neither of these things are things I would typically do in the view.
For a small app, I might use the param object for re-populating a form that has failed validation but, in most cases, by the time validation fails, I've already used those parameters to populate a bean and it's easier (or clearer) to use the bean's properties to repopulate the form.
I agree with Ben in that you are probably best dealing with business logic before you get as far as the template. I'd probably consider it a bit of a code smell if you feel the need to tinker with the response headers, cookies etc in a template. I'd be taking a step back and havig a coffee to think things over at that point ;)
The only things I deal with in the view layer are model data which I'm rendering a view for, view helpers and very occassionally an arbirtrary request parameter.
It makes sense for EL to make them available for ad-hoc times when you may find a need for them, but I wouldn't encourage putting that sort of logic in templates much.