Language author here; I work on a modern flavor of a classic 90s language.
There are three problems. The first is that closed languages die [0]. V is not Free Software, which is disappointing but not atypical; however, V is not even open source, which precludes a healthy community. Additionally, closed languages tend to have bad patterns like code dumps over the wall, poor community communication, untrustworthy binary behaviors [1], and delayed product/feature releases. Yes, it's certainly embarrassing to have years of history on display for everybody to see, but we all apparently have gotten over it. What's hiding in V's codebase? We don't know. As a best guess, I think that the author may be ashamed of the particular nature of their bootstrap.
The second is that V's author makes promises and claims which are then retracted, falsified, or untestable. Most notably, source for V's toolchain has been teased repeatedly as coming soon, but has never been released. Without an open toolchain, none of the claims made on V's front page [2] can be verified.
Finally, because we can't not talk about it, V isn't a very compelling language. At best, it could be seen as an iterative improvement on Go. If V were more open, then we could make more sincere and complete comparisions, but as it is, V's author alone gets to control the comparisons [3] and benchmarks [4]. Maybe the best argument to be made is that there is room for a series of languages which focus on compile speed, where languages like Go, Jai, and V compete based primarily on how quickly they can transform zero-cost abstractions into low-level code in a single pass.
...But if that's the game, then it's only a matter of time until one of them rediscovers FORTH...
[0] https://blog.golang.org/open-source
[1] https://github.com/voltapp/volt/issues/143
[2] https://vlang.io/
[3] https://vlang.io/compare
[4] https://vlang.io/compilation_speed