OO system is a free, open source package for OOP in Mathematica. By using OO-System I hope to benefit from the best of both worlds (OOP/Functional).
A disclaimer: I have not used any of the existing OO mma extensions (and OO System in particular), so this post is based on general arguments (but I used OO heavily when worked in Java, and used some OO elements in mma, which I implemented myself). I agree with the opinion that OO is a moving target, so you have to be more specific in terms of features you want, to get a more useful answer. It also greatly depends on what are your goals - do you want to simplify your own life and make your own project scale, or do you want to simplify the communication for the project which is going to be developed by several (many) developers, and enforce certain rules and protocols (coding standards, best practices, design patterns, whatever), or do you want OO to reuse existing libraries.
I'd argue that most of OOP use in the industry fall into the second and third categories. If this is also your case (which I suspect it is not), then it may make sense to use OOP in Mathematica, although even this is not clear. WolframAlpha, for example, has tens of millions of lines of code in its codebase, and AFAIK no OO system was used there. If you want the benefits for the solo developer, then I'd choose those features of OO that I like and implement them myself - i.e., create your own object model. This is not too difficult in Mathematica.
It would make much more sense to use some specific OO extension of Mathematica if there would be a large number of well-tested open-source libraries built using this extension, with an easy deployment mechanism. I am not aware of any significant mma code base (libraries) built with any of existing OO mma extensions (which could as well be due to my ignorance). So if you need OO to reuse existing libraries, then things like J/Link or .Net/Link may serve you better, since you will have access to all of Java or .Net.
If you want the techniques to scale your project, then OO is not your only friend. While this is probably not a very well explored territory for mma (except may be by WRI), some techniques from other functional languages such as closures, LISP macros, run-time code generation, etc, may well be applicable to mma. For example, one of the mma projects I am working on has more than 40 packages and more than 10 thousand lines of mma code, and it is quite managable (with WorkBench). I am using closures and macros a lot, and also some OO features, but not any generic OO extension. The important things are information hiding, lose coupling, composability and testability, and again, OO is not the only way to do that.
IMO, one very nice thing that could be accomplished by an OO-capable language layer in mma (perhaps, Python-like) would be to hide the complexities of the evaluator and pattern-matcher, because in many cases those are not needed and may be confusing to less experienced users. I was (and still am) missing such language layer quite a bit at times. The designer of such layer will face a hard task of making it really well integrated with the rest of mma. Apart from that, I see the two major obstacles for a generic OO system built in the top-level mma: slow performance and no automatic garbage collection. I think, until these are solved, they rule out the heavy production use of OOP at the lower-level (creating millions of objects etc). Some features of OOP may still be quite useful for high-level project architecture, but as I said, they are easily implemented. This is not to say you should not try existing OO extensions, I'd just weight their benefits specifically for mma against the necessary limitations they will impose on your code.
