Now there's an attack surface. If you can put a rewrite to a fake site into the EFF's database, what happens?
Also it looks like[2] some rules are built in such a way that only the protocol is changed and the domain is left as-is.
[1] https://github.com/EFForg/https-everywhere/tree/master/src/c...
[2] https://github.com/EFForg/https-everywhere/blob/master/src/c...
There are also scripts that indicate whether rules redirect to non-HTTPS targets and whether the rules contain non-ASCII characters (to avoid homoglyph attacks, like <rule from="^https?://www\.paypal\.com/" to="https://www.pаypаl.cοm/">).
Because of the challenges of parsing PCRE with backreferences, there are no scripts that check whether the target domains are the same as the source domains (and there have been a small number of rules that did intentionally rewrite to a different domain). These do get read by human beings before being included in the project, and traditionally new rules are included for months in the development release before being migrated into the stable release, but it would be a great thing if more human beings would check them, or help develop scripts that do so in new ways.
One idea that we've talked about in the past is to divide rules into simple and complex, and then single out only the complex rules for extra human auditing. (Simple rules would be syntactically constrained not to rewrite across domains.)