ECB leaks the identity of aligned 16-byte blocks.

An image may have large areas of uniform color, so it will definitely leak through ECB, unless the original image was noisy, which prevents repetition, so nothing is revealed after encryption, even when using ECB.

The famous encrypted penguin works only because the original image is a noiseless drawing. Had it been replaced by a photographic image, the ECB-encrypted image might have looked perfectly random and undecipherable. In general, it is enough to use a very simple non-cryptographic PRNG, e.g. a LFSR, to add white noise to an image before using ECB encryption, to make the encryption unbreakable (a.k.a. indistinguishable from a random string by chosen-plaintext attacks).

On the other hand, normal text, such as SPICE model text, even if it has a lot of words that are repeating, it will seldom have 16-byte sequences aligned at 16-byte boundaries, that are repeated.

Even if you see a few such repetitions, it is extremely unlikely that you will succeed to guess even a small part of the model text.

Here the problem was their key generation method, which produced guessable keys, not the use of ECB.

If you know cryptography, it is easy to use ECB in a perfectly secure way, e.g. when encrypting only values that can never repeat. The reason why it is strongly recommended to not use ECB, is that naive users cannot judge when the use of ECB is appropriate and when it is not.

Moreover, even if ECB can be used in a secure way, its hardware implementation is more expensive than of alternatives, because it must implement both the encryption mode and the decryption mode of the block cipher function. So the reason why there is no need for ECB is that the alternatives (i.e. Vernam encryption a.k.a. binary additive synchronous stream ciphers) have a cheaper implementation, even when using the same block cipher function, and not because one cannot use ECB in a secure way.