In general I would say it is a good practise to have at least one person (tester/qa) in the team who is in the lead with regards to functional testing. By having this person constantly focus on tests and testability of end user functionality, this forces the whole team to also think about this (even when the tester is not there).
I've worked many years as a tester and initially I also had the opinion that EVERYTHING had to be tested by a tester. I have changed my opinion about this and I would now encourage most developers to also participate in functional testing (that does not mean that it will be successfull with any developer though).
- As a tester you don't want to be the single point of failure of the team; if other team members that have some interest in taking responsibility for the quality are trained to get some basic testing skills, you at least have them execute the test cases that you wrote. On critical moments in a project or sprint, this is really valuable. It is also valuable that you can take a few days off without worry.
- When working with Behavior Driven Development/Acceptance Test Driven Development, programmers are forced to get the functional tests to work themselves. They are basically executing the functional tests themselves and this makes sure that they implement a new features the right way the first time. This is a huge benefit obviously.
- Functional tests are scenario's that can (or would be) executed by end users without any knowledge of the implementation. That doesn't mean that you can't use information about the impmentation to write these tests. Perhaps there is some need to refactor some code for technical reasons. As a tester I would be very interested in how that code relates to end user functionality, so I can choose which functional test cases I would execute to see that there is no regression.
- When you are serious about test automation, you should consider using the Test Automation Pyramid model. This suggest that you try to minimize the amount of manual and automated functional tests and try to cover as much in unit and integration tests. A tester can only get confidence about the coverage of the technical tests if he/she knows what they are doing and why there is no need anymore to test the same functionality in (automated) functional tests. This thus requires the tester to know more about the code.
To me, the context where you are in is very relevant in the choices that are made about the distribution of testing work within the team.
If the skill level in the team is very low with regards to testing/quality process; it is probably a good idea to stick with the 'tester does everything himself' approach.
For teams that have high ambitions for quality AND delivery speed, it becomes increasingly important to adopt skills from other roles in the team ("T-shaped").