Didn't veracrypt creators know about this issue?
(Not having brute-force protection)
As Andrew Morozko notes in his answer, they have addressed this – as far as it is possible – by using a secure key-generation function (PBKDF2) and high iteration counts. This severely limits the ability to brute-force (assuming the password is long- and random-enough1).
What other methods do you think they might have used?
On a website, where the software policing login attempts is owned by the defender, you can do things like rate-limit login attempts (with increasing delays, way beyond the actual computation time for checking the password) and lock the account after too many failed attempts.
However, with VeraCrypt, the software handling an encrypted volume will be sat on the attacker's machine, and must therefore be considered "owned" by the attacker. Even if the writers were to have incorporated code to rate-limit attempts, it would be "trivial" for someone to reverse-engineer the binary and remove/bypass the rate-limiting code.
Conclusion: virtually2 any measure above and beyond what is inherently required to check the password would be useless and easily circumvented.
1 The two references you cite to claim that "a veracrypt encrypted volume can be easily brute forced" do not, in fact, show this. One is where the correct password is known to be in a list of "1000-2000" candidates; the other where "most of the password" is remembered. The first is clearly trivial; the second depends on how much is unknown/unremembered, but neither is a "typical" brute-forcing scenario. As Andrew says, "If your password is secure against dictionary attack - you can have high degree of certainty in the security of your data.".
2 About the only possibly conceivable method I can think of would be where the process of credential validation involved (and required) talking to servers under someone else's control. For example, if some part of the key-generation process (during both encryption and decryption) necessitated passing elements through, say, VeryCrypt's servers then they could, in theory, impose extra rate-limiting or lock-out measures.
However, even if this could be done (in a way that was both cryptographically necessary, but didn't leave copies of the keys with VeraCrypt) it would be unacceptable to virtually all use-cases: requiring a working internet connection every time someone mounted a drive, and any encrypted volumes would be come useless should VeraCrypt (and their servers) cease to be.