The problem with ECB is that you must know when to use it. It is not recommended only for the people who do not know cryptography, so they are not able to judge when the use of ECB is right and when it is wrong.
ECB is as secure as any other mode of operation if you only encrypt values that are never repeated, e.g. values produced by a counter, or if you encrypt values that have negligible probability of repeating, e.g. random values, such as secret keys. The defect of ECB is that if the adversaries would ever see the encrypted form of 2 identical values, they will know that those values were identical, which may help them to decrypt the message, or not, but such a risk must be avoided.
As another poster has said, here the main problem was the key derivation method used by them, which produced low-entropy keys that can be found by brute-force search.
In general, it is quite rare to be able to break even the weakest methods of encryption that are used today, when they use appropriate secret keys.
The method used for secret key generation is almost always the weakest part, which can frequently be broken.
... and you're not worried about an attacker swapping around any block of ciphertext they want at their leisure, for example the block containing someone else's encrypted bank account number for the actual payee's bank account number. Or several other issues, look up "ECB penguin" for an example.
But the main issue with it is that it's a huge red flag. Seeing ECB being used is a signal that whoever wrote the code has no idea what they're doing, which in turn is an invitation to look further for all the other things they'll have got wrong.
No method of encryption is secure against active attacks unless it is used together with an authentication method. This is equally true for ECB and for any other mode of operation of a block cipher and for any other method of encipherment.
Of course the use of ECB was inappropriate for this application, but despite this, the weakness of ECB is not enough to allow the decryption of encrypted SPICE models. Repeated blocks of 16 bytes aligned on 16 bytes boundaries would be very rare and even finding such repetitions in the short SPICE models is extremely unlikely to allow the guessing of even a small part of a model, which would still be useless, as only a complete model is useful.
So the use of ECB in this case is weird and it is a red flag about the competence of the implementer, but the use of ECB alone would be pretty much impossible to exploit for the decryption of SPICE models.
ECB is as secure as any other mode of operation if you only encrypt values that are never repeated, e.g. values produced by a counter, or if you encrypt values that have negligible probability of repeating, e.g. random values, such as secret keys. The defect of ECB is that if the adversaries would ever see the encrypted form of 2 identical values, they will know that those values were identical, which may help them to decrypt the message, or not, but such a risk must be avoided.
As another poster has said, here the main problem was the key derivation method used by them, which produced low-entropy keys that can be found by brute-force search.
In general, it is quite rare to be able to break even the weakest methods of encryption that are used today, when they use appropriate secret keys.
The method used for secret key generation is almost always the weakest part, which can frequently be broken.