Basically there are three things that can fail (well, I am sure a computer somewhere can come up with number four that I didn't think about):
1) The plugin is not loaded
This is easy to verify - set the log to verbose and restart the TM service. In the log file should now contain an entry that will be either (assuming English logging)
Loading plugin with the assembly name: X
Loading the plugin from the file path: X
If you do not see one of these lines identifying your plugin, there is most likely an error in the TranslationManager.xml configuration file.
2) The plugin is loaded - events do not reach it
On a development environment this is easy to check: Just attach a debugger to the Translation Manager service and let a job fail. An easy way to fail it is to have a user check out one of the components being translated. Make sure to check it out in a target publication, and do not use the same user the Translation Manager service use. You can use Retry Retrieving to clear the error and regenerate it on next retrieval attempt - this way you do not have to generate new test jobs for each test.
If you can't hook up a debugger then you can add logging information at the entry point to the event handlers.
If your event handler is not called, then check you have hotfix TT84775 or newer installed. If this is not the case, contact SDL customer support to get the hotfix.
3) The plugin is called and compose the email - no email.
If this is the case you should see the following in the log:
Sending error notification email to:...
If you see this log entry then the plugin is attempting to deliver the email. The problem would then most likely be in the configuration of the SMTP server in Translation Manager.xml - or configuration on the SMTP server itself (it might not be configured to allow your server to send email). I assume you already checked the email address the email is being send to is correct :)