TL;DR
Anytime an attacker has physical or logical access to private key material—even if encrypted at rest—one should certainly consider revoking the exposed keys. In your particular case, you should assume a compromise and act accordingly.
Why You Should Revoke Your Keys
Even had you not violated the principle of "thou shalt not reuse passwords," the fact is that a local attack or an attack on extracted/copied key material is not rate-limited. So, assuming Apple, Google, or the NSA really want to attempt to brute-force your encrypted key, they can do so much more effectively with access to your on-disk key.
Since it would be common sense to try any known passwords before embarking on a brute-force attack, you can (and should) assume that any knowledgeable attacker will do exactly that. Never assume your adversary is an idiot.
In your particular case, you gave the attacker both physical and logical access to your machine. It is both possible and likely that backups of data were made, so even if the technician isn't your direct adversary, you now have no assurances of who has access to your key at rest, or what computing resources may be brought to bear on it.
In short, you handed over your key with your key's passphrase metaphorically (and possibly literally, by the technician) taped to your monitor. You'll likely never know if you were compromised, but you should certainly assume that you could have been.
Why You Might Choose Not to Worry
While Apple (as a company) has plenty of computing and storage resources for backing up your secrets and mounting brute-force attacks on them, it seems unlikely to be in their direct interest. They sell products and services that consumers would like to believe are secure, so deliberately violating that security and trust would be a bad business decision.
Having said that, individual technicians might still be bad actors. However, this possibility is tempered by the fact that Apple techs are unlikely to be professional cryptographers or forensic specialists, and are generally busy people without the time to waste poking around on people's hard drives without a bit more of an incentive than you've identified in your post.
A more likely scenario is that Apple might get a National Security Letter asking them to turn over any data they may have. The NSA certainly has the training and the resources to comb through your files and apply common-sense forensics to avoid brute-forcing your password, but unless Apple is routinely handing over all customer data as part of some bulk collection activity (see above for why this is possible but unlikely), you probably don't need to lose a lot of sleep about this particular scenario.
Finally, threats are all about consequences. Assuming you aren't smuggling state secrets, or have your off-shore accounts and human-trafficking contact information encrypted with the potentially-compromised key, the logical question to ask is: Even if the key was compromised, so what?
If your damage potential is low enough, you could probably go around handing people your private key all day long without serious consequence. I'm not recommending you do so; it's just worth taking your actual risk profile into account to properly assess threats and the consequences of compromise.
Note to Apple Customers
Apple does this a lot, e.g. asking customers to unlock their drives as part of their diagnostic and repair processes. They claim they need access to the OS stored on the FileVault-protected partitions in order to run diagnostics. There may be a technical reason why they can't use a boot disk or network boot to spin up their diagnostics, but without more information I consider it suspect.
As a general rule of thumb, it's best to back up your drive and blow away the FileVault partition before going in for service, or letting them do it for you. While it doesn't make a lot of sense to distrust your hardware or OS vendor, neither should you hand anyone sensitive data on a platter. Just be aware that asking for FileVault passwords is S.O.P. at Apple repair centers, and plan accordingly.
