No, the problem with style A and B is that smallFunction() might have only been correct under the context of it executing inside largeFunctionA(). IMO this risk is actually increasing even more if it originates from a refactoring from style C, since you didn't design smallFunction() from bottom up considering all possible use cases, you most likely just highlighted a random block in largeFunctionA() because it was getting too big and clicked "extract method" in your IDE.
Imagine two months later someone writing largeFunctionB() is browsing around the code and finds smallFunction(), thinking it will do the job he requires but actually it has a hidden bug that was never triggered under the context of it executing in largeFunctionA or under the limited input range that largeFunctionA was using.
See in particular this paragraph from the article:
Besides awareness of the actual code being executed, inlining functions also
has the benefit of not making it possible to call the function from other
places. That sounds ridiculous, but there is a point to it. As a codebase grows
over years of use, there will be lots of opportunities to take a shortcut and
just call a function that does only the work you think needs to be done. There
might be a FullUpdate() function that calls PartialUpdateA(), and
PartialUpdateB(), but in some particular case you may realize (or think) that
you only need to do PartialUpdateB(), and you are being efficient by avoiding
the other work. Lots and lots of bugs stem from this. Most bugs are a result
of the execution state not being exactly what you think it is.
