Why? Vim is a well tested codebase. It has many features. Starting over would produce better code, but in what timeframe? I think the neovim contributors made the right decision to refactor.
Tests are being added all the time, and patches from upstream Vim integrated. Moreover we do have a reviewing process in place (mostly 2 or more people looking over the code), travis runs, all vim tests + lua unit tests are run for each PR. Coverity scans every 2 day to see if nothing slips through. Most PRs are actually simplifications of old code, afforded by depending on libuv and using an abstraction of malloc that doesn't return NULL (note that vanilla Vim was never safe against malloc returning NULL, as was tested by @philix by using the fail allocator). Granted, the new features that have been introduced, like job control, see comparatively little use at the moment but do receive review and are used to replace other things that are used a lot (such as VimL system()). By the time we get a second release, I'm confident it will be pretty well-tested, we are preparing for it.
To add on what @aktau said: soon we will have much more robust UI tests.
The current UI tests are hard to write and based on the ASCII output [2] of the commands of the test [1]. By using the Neovim API we will be able to rewrite these tests to look more like automated Sellenium based web app tests and make more fine grained assertions.
