One thing is that a lot of testers are still working in a very rigid way. First, design and write down the test cases (based on a specification that is most likely flawed and incomplete). Then, perform the tests. Then, document the results. There is very little room for creativity and exploration in such a process.

This is basically what you do when you write automated tests, except the execution (and reporting) steps will be done automatically and repeatedly. Which is super valuable, but when a skilled tester goes at it, there will be ideas and crazy connections flying around everywhere. Even if many of these tests were to be automated (which in many cases really isn't feasible, considering implementation time/execution time/maintainability costs), you'd need someone to even think up the tests, and typically developers don't have the time or breadth of knowledge of their system to do it.

I used to work in a team with 5 developers and me as the tester. Besides finding tons of bugs - many of them very subtle - I became the one person who understood the product best since I was the only one touching all parts of it, so I was the one people came to for questions. Now, working as a developer, I do write automated tests, but I refuse to release anything our tester haven't had the time to test yet.