Naturally we do take a very hard line on spam, and obviously an author putting malicious code into a plugin is enough grounds for us to bring down the ban hammer.
But there are natural circumstances where an author may not be at fault. For example, if his password had been used by malicious persons without his knowledge, then we wouldn't hold the plugin author responsible for that, but would work with them to clean up the plugin, secure their account, and advise them on how not to let it happen again.
In this case, the original author of the plugin and the current maintainer of the plugin have made it clear what has occurred here. Basically, the current maintainer is not a professional programmer, and put his trust in the wrong freelancers to do the coding work for him. Though he did check in the malicious code, it's clear from our communications that he was unaware of its nature. Both me and Scott have examined the current plugin code and determined that it has no malicious intent (after we removed the problem code), and it would be unfair to the users of the plugin as well as the current maintainer to have an absolute "zero-tolerance" policy for all cases.
People make mistakes. In this case, the current owner of the plugin put his trust in the wrong place. I'm confident that he won't do that again, and regardless we'll be watching the plugin for changes. Anybody else is free to do so as well, it is easy to subscribe to the plugin changes via email, and get notified of every commit to a plugin's code.
So the plugin is back up for now, and as long as it stays clean, it's fine. :)