It is very possible to write completely non-OO code in an OO language.
Of course all of these people completely missed the point, and their code was incomprehensible and unfixable. OO analysis is about breaking a problem down into conceptual kinds of things and their relationships. OO programming is about modelling these kinds of things in code as a hierarchy of classes. In all the examples above, nothing remotely like that happened (although in each case, it would have been profitable.)
Having a hammer doesn't make you a good carpenter. A thing beaten with a hammer is not a house-frame.
OO programming does not make a good programmer of a bad one. OO methodologies can be miserably badly applied, resulting in incomprehensible, unfixable, nonfunctional code.
That said, in the hands of careful and experienced software developers, OO methodologies can be a real life-saver for a programming effort.
Inheritance is a powerful tool, and it's a common mistake among initiates to get carried away with it, applying it for purposes that it isn't well suited for.
The most common of these misuses is to use inheritance to model technical implementation. This is worst in languages that permit multiple inheritance. So a perfectly conceptual class such as Employee will be mixed with an implementation class such as DatabaseEntryClient. Of course this can work... but for the next reader, the code of the two issues, is mixed up.
The deciding question in designing a class structure has to be: are such properties and behaviors essential to the thing? If instead they are just a way to make it work, they should certainly not be part of a class public interface, and they should not be present in the conceptual class structure.
The result of this is that the otherwise simplifying heirarchical structure of essential concepts tangled with implementation issues. As the point of the OO exercise is simplification and clarity, this is counterproductive.
While both the real-world problem and the internal implementation problem may be implemented in OO ways, it is a mistake to mix them, to tangle the inheritance tree for the real-world problem with that of the internal implementation. You may get the thing to work, but it is a conceptual mess, and the parts are highly coupled and therefore not re-usable. The conceptual class trees should be kept quite separate.
There are several much superior options for modelling implementation in an OO environment. Usually they involve the use of a non-public proxy implementation member of the main class object, which takes care of the extra details. Such proxy might be injected into the object on creation by a Factory object, whose job is to relieve the main class object of the question of just which implementation it will get. For this purpose, the main class might implement a non-public interface, that give it the ability to be injected with such a behavior.
For some kinds of services, in some languages, it is popular to use fancy language features to inject behaviors into objects, with no code whatever for those behaviours being present in the main object. For instance, an ability to "log" or "print" an object might have nothing at all conceptually to do with the object. Rather than making the object inherit from "Printable" or "Loggable", the object is injected with the capabilty when it is created by a Factory object. (There are several Java frameworks for this in wide use.)