Hey Space Friends,
TL;DR We're well aware of this and are working on a fix ASAP!
To give you some background on how this happened >
EWar Resistances
During the initial change introducing EWar Resistances, we introduced a new attribute called remoteResistanceID. This defined what type of resistance the module would face. So ECM modules would have remoteResistanceID defined as ECMResistance. Sensor Dampeners would have remoteResistanceID defined as sensorDampenerResistance.
When a Neut/ECM/Sensor Dampener/etc. tries to effect its target, the effect on the module would first look to see what the resistanceID on the module, then use that ID to see what the resistance is on the target. If the resistance is too high (actually too low, 0.10 = 90%, .90 = 10%), then the effect will fail.
This works really well for player ships and modules. A player ship might have a ECM Module and a Neut Module. Both the modules will have their own remoteResistanceID defined. This doesn't work so well for Entities. NPCs (which are Entities) don't have modules. All of the attributes are on the Entity, not on seperate modules. So for an NPC that Neuts, or Sensor Dampeners, thats fine. The effect will just look up the remoteResistanceID and continue as per normal. But, what if the NPC has two EWar effects. What if it can Neut and Jam. We can only set remoteResistanceID once on the NPC. When it Neuts and Jams it will try and use the same remoteResistanceID, and for one of them it will be the wrong type. This is why NPC's didn't respect EWar Resistances for a while.
So, we approached this problem from another way. Each effect (Neuting, Jamming, Weapons, etc) has some of its own attributes. These are all just pointers. So for example, the ECM Effect has attributes that tell it which attributes to use for Range, Falloff, Cycle Time, Capacitor usage, etc. We added another attribute on the effect called resistanceID. We could define that attribute to tell the effect what to look up on the target and use as resistance.
This was a pretty simple change. A new column in the DB, some refactoring of the ECM code and sweet.
Development Process
So to give you some insight on how this works (simplified):
•First the dev makes the changes on his local version of EVE. And tests it. Once She/He's happy with the changes it gets submitted.
•Next the team QA will build a full build of the server & client on his local machine and test the changes.
•Then an internal server is built with all the changes. This is tested by our outsourcing QA partner (shout out to Pole to Win!)
•Then we push the changes to Singularity, where both we, PTW, ISD, and you guys test the features.
•Finally, on patch day, we package up the changes and push them to Tranquility.
Fail
That last step is where we've had a problem with the ECM resistance. This specific change involves 3 parts :
•Create a DB Column
•Set that Column to the correct resistanceID value
•Change some ECM code
And that change worked perfectly for every step of the development process...except the last. The order of the first two steps got messed up. The column value was set before the column was created. Or rather, the column value was attempted to be set, but didn't exist, so failed. Then the column was created with its default value (null). So now those ECM Effects on TQ don't have any defined resistanceID.
Our awesome DBA's are chasing down why this happened and ensuring it won't happen again. Along with fixing this issue.
Honestly, when I first started looking into this report I thought the OP was trolling me. I tested on my local server, on an internal test server and finally on Sisi, and at every level the ECM Resistance was working...Thanks to /u/NoobmanHK for checking on TQ for me

Anyway, I hope that gives some insight as to why this bug exists and our process. I'm sorry it exists. We're fixing it ASAP!
Cheers,
CCP Larrikin