Important lesson: your confusion is not your fault. The literature sucks.
So part of the problem you are running into is that there are many definitions of "unit test", which aren't all consistent with each other. Furthermore, there are multiple reasons that someone might want a "unit test", and the different reasons that you might want them introduce different constraints on the design of the test.
Design is what we do to get more of what we want than we get by just doing it.
The constraints of "unit tests" follow from the "what we want".
For example, if your "unit tests" are tests written by developers for developers (for example, when practicing Test Driven Development), then one of the important constraints is that the suite of tests should be eyeblink fast (because they are going to be run so often, and we need to ensure that running the tests doesn't introduce a delay long enough to trigger a context shift).
So when Michael Feathers wrote in 2005:
A test is not a unit test if:
- It talks to the database....
Feathers is working specifically in a context where the developer's attention is on improving the internal quality of the design; the extra overhead of talking to a live database, even a managed one, puts the flow in jeopardy.
On the other hand, if you are creating unit tests for testing (for example, to catch errors before your changes are automatically deployed to production), then different constraints are in play -- we don't have to worry about our test automation getting distracted by testing delays, and this eases some of the constraints that impact the design of our "unit tests".
As for why Khorikov's answers seem to be inconsistent... well, the generous answers are that he learned something during the interval between writing those things, or there may have been some subtle difference in context that changes his recommendations.
Less generously: perhaps he's just wrong. It happens.