As others have said, it depends.
Testers do not need to understand code to be good testers. Testers who do understand code can use this knowledge to their advantage, but this does not automatically make them better testers than testers who don't understand code.
Your example of testing the same module in different locations misses the context: the base code of the module may be no different, but the pathways into that module are different, which introduces the possibility that one pathway may not be passing the correct information (or sufficient information) to the module.
For instance, say you have a form to collect or display contact information. The form can be invoked from a completed order, during the order process, during the invoicing process, and from the contact management module. You can create a contact during the order process and from the contact management module. This simple set of rules means it's necessary to test that you can't create a contact from a completed order or during the invoicing process. It also means you need to make sure that when you create a contact during the order process that contact is correctly associated to the order. In addition, you need to make sure that in all four scenarios, all the information you need is available when you view a contact, and that modifying the contact is available when your business rules dictate. In all these situations, the underlying code is no different, but the pathways into the code and the business rules around it vary.
Timing, performance, and threading issues tend to be more difficult to test manually anyway - issues like that are more likely to show up under automated testing and load testing, which tend to be their own specialties. Typically I'll be alerted to a potential timing/performance/threading issue by automated tests, and I'll do some manual investigation to dig further and try to force the issue - but I may not be able to because in some cases it's simply not possible to force something without having the application code running with breakpoints.
Don't underestimate your manual testers. The amount of work they do with the application means they have a good idea where problems are likely to occur, and they will cover this in their planning. They're used to the idea that they need to cover as many decision pathways through the application as they can in the time they have available. It may look to a developer like they're retesting the same code repeatedly (they are), but they're testing it through different pathways. They know that bugs happen in the communication between modules as well as in the modules themselves.