The fundamental part to this is that the coder's responsibility is to create code that works and fills the requirement. This requires a particular mindset - "The code that I am writing does what it is supposed to do."
To mix the responsibilities of the coder means that the coder is now required to enter other mindsets for other activities, however, as a coder, it is difficult to impossible for one to completely divorce one's self from that mindset.
The tester's responsibility is to find bugs and places where the functionality diverts from the required functionality. This required the mindset of "The code is broken and I will find out how."
Likewise, a business analyst is trying to identify the requirements that the customer is actually asking for. This requires another mindset of "the application doesn't work this way, but it should."
For a coder to work in any of those other capacities, there is a reasonable likelihood that the mindsets will conflict and the coder will perform sub-par:
- Coder/QA - "The code works perfectly, and I have already coded to
handle every possible way I can think of that might break it."
- Coder/BA - "The code should work the way that I want it to and these
would be neat things to add to it that the customer didn't think of.
This is not to say that every coder is susceptible to these problems (I have meet some very gifted coder/QA types... though not for code that they wrote).
This extends up to the development team as well. Mixing the responsibilities and associated mindsets of those responsibilities for a development team compromises the final product (the code).