I could imagine that such tool as Hammurapi could be useful where a project employs a lot of code monkeys ...
I agree with "a lot", but "code monkeys" sounds offensive. The valid term is "offsite contractors" or "persons not familiar with organization's coding practices and standards".
Software engineering metier, like probably any other, has different embodiements, such as art, artisanship, and mass production.
In case if your project is executed by a small group of virtuoso with plenty of time to do everything right there is no much value of Hammurapi 'out of the box', though you can use it for project metrics.
At artisanship level Hammurapi is a tool to communicate coding standards to apprentices and save masters' valuable time.
But the most value of it is at shops which produce code and outsource massively. In this case Hammurapi is not only "knowlege crystallization" tool, but also a contract enforcer between code developing organization and client organization. Because Hammurapi is free, client organization can publish its inspector set to Web and expect code developing organization comply with published standards without additional cost for the client as it would be if client used commercial tools for code reviews.
I work in an organization where we have about a hundred of projects in production. Most of them are very similar to each other. 85% of development is outsourced and 85% of these 85% are offshored. Every project lasts about 3-6 months and after that project team is dismissed and project's product goes to support team, which is also outsourced and offshored. And we have only four architects. Hammurapi helps us to enforce coding standards and find potential problems from reports, not from production issues troubleshooting.
Small teams and "Agile" methods are cool, but just not applicable to an e-factory with a big number of relatively small projects being developed simultaneously and volatile project teams. It is a separate big topic, though.