This is a pretty good example about refactoring discipline as well as premature/over optimisation.
We all want to see more modular code, but the first steps should just be to relocate blocks of code so everything is more logically organised in smaller files (especially for consensus critical code). Refactoring should come in a second wave preferably after a stable release. Refactoring should be in the pure sense, optimising code with absolutely no change in behaviour.
When it comes to actual API changes, I think we need to be a lot more careful and should be considered feature requests and get a lot more scrutiny as we are essentially breaking backwards compatibility. #4890 was pretty much merged with no discussion or thought yet other really simple and uncontroversial PRs remain unmerged for months. A key question in the case of EvalScript() would have been, "why are we passing txTo and nIn here, and are there any future use cases that might require them? Why should this be removed from the API and the entire method signature changed?". BC breaks always need strong justification.
So I've expressed my concern a few times about the speed and frequency of refactoring and also the way it's being done. I am not alone, as others not directly connected with the Bitcoin Core project have also expressed concerns about the number of refactorings "for the sake of refactoring", especially of consensus critical code. Careful as we may be, we know from history that small edge case bugs can creep in very easily and cause a lot of unforeseen problems.