I agree that an accountant should not aim for the same depth of detailed knowledge as a developer (unless he means to be one himself, in which case he should stop being an accountant), and shouldn't try to descend to code level. That's not his job-skill, so he should respect that and depend on developers to tackle that aspect of the work instead of trying to butt in.
An accountant should thoroughly understand where his job ends and where that of a developer begins (since he's the one with the opportunity to cross the line). As you say, he has a different contribution to make to the team.
On the other hand there's nothing wrong with an accountant getting to understand a little about what developers are doing. Like what makes a website tick and what developers are doing. Programming isn't rocket science after all, and mostly consists of getting lots of stupid details right quickly and reliably. Getting a feeling for how a website actually works could be quite helpful (as long as he remembers to think about (and ask for) functionality, not implementation).
My suggestion to this accountant is to look at up to three past projects that went well, and three that went wrong, and figure out what the root causes for success and failure were in terms of what business process was served in each case, what was asked for and how (organically grown versus properly specified and designed), and how the team that did them worked.