Block size does matter for security, but only up to the point where there is no possible attack with plausible technology. In a nutshell, an n-bit block cipher is safe for use with up to a little less than 2n/2 blocks of data encrypted with the same key. The n/2 figure comes from the birthday paradox: that's when you get a macroscopic chance of repeat values if you draw blocks at random. For a 64-bit block cipher, that means you must not encrypt more than a few gigabytes (264/2 blocks of 64 bits is 32 GB). Sweet32 is an example of a concrete attack against a cipher (3DES) due to its small block size.
AES has a 128-bit block size (regardless of the key size). This is safe up to exabytes of data encrypted with the same key.
For more information on how AES's block size was chosen and some examples of attacks that are practical with a block size that is too small, see Difference between Rijndael 128 / 256 blocksize implementations? (and impact of block size in general).
So there is no security benefit to “AES with a 256-bit block size” compared to regular AES. Worse, “AES with a 256-bit block size” has security problems that regular AES doesn't have.
The first problem is that “AES with a 256-bit block size” does not exist. AES is a 128-bit block cipher. All there is is Rijndael with a 256-bit block size and whatever number of rounds. Since it is not standard, most cryptography libraries do not implement this 256-bit-block variant. This limits you to a few implementations or possibly a home-grown one, instead of implementations that have had solid scrutiny and are actively maintained. For example, you may have a hard time finding an implementation that has been hardened against timing attacks and other side channel attacks — in cryptography, getting the correct result is far from the only requirement.
Another problem is that AES specifically has had more scrutiny than Rijndael in general. It's possible that some attacks only apply to a specific set of parameters, for example a specific block size. A known example is that related-key attacks (which do not matter in practice) are markedly worse against AES with a 256-bit key than against AES with a 128-bit key.
A third problem is that since the parameters they're using are non-standard, you have less confidence that these API designers chose the other parameters securely. In particular, a larger block size requires more rounds (Rijndael proposal, 7.6). If they kept the same number of rounds, or worse if they chose a lower number of rounds to compensate for the lower performance of larger blocks, this could make the result easier to break. There are known attacks against AES with a reduced number of rounds, which no one knows how to use to effectively break the full number of rounds, but which might apply to a Rijndael variant with custom parameters.
All the risks of using a non-standard Rijndael variant pale against the use of ECB. Using ECB shows a basic lack of understanding of cryptography. The classic picture where patterns are clearly visible is just one of the problems with ECB that happens to be easy to illustrate graphically. Encryption without authentication also tends to allow a large class of attacks called oracle attacks, where the attacker sends encrypted blocks without knowing their content and observes how the party with the key behaves. What oracle attacks might be possible depends on the protocol, but ECB is not randomized (no IV or nonce), which tends to make such attacks a lot easier.
In a nutshell, the use of non-standard cryptography and the use of ECB are both red flags against the security of a product.
