OOP itself hasn't changed much since its inception. A few new angles to it have been explored, but the core principles are still the same. If anything, the collective knowledge gathered over the years makes the programmer's life easier rather than harder. Design patterns are not a hindrance; they provide a toolbox of solutions to standard problems, distilled from years and years of experience.
So why is it you perceive OOP today as more complex than when you started using it?
One reason may be that the code you are being exposed to becomes more complex - not because OOP has become more complex, but because you have advanced on the learning ladder, and get to read larger and more complex code bases.
Another reason may be that while the complexity paradigm hasn't changed, the size and complexity of an average software project may very well have. With processing power available on customer-grade cellphones that would have been a developer's wet dream on a server less than two decades ago, the general public basically expecting slick animated GUI's for even the cheapest throwaway app, and entry-level desktop PC's being more powerful than a 1980's "supercomputer", it is only natural that the bar has been raised since the early days of Smalltalk and C++.
And then there's the fact that in modern applications, concurrency and parallelism is the norm rather than the exception, and applications frequently need to communicate between different machines, outputting and parsing a whole zoo of protocols. While OOP is great as an organizational paradigm, it does have its limitations, just like any other paradigm: for example, it does not provide a lot of abstraction for concurrency (most implementations being more or less an afterthought, or outsourced to libraries entirely), and it's not the best possible approach for building parsers and transforming data. Modern programming frequently runs into the limitations of the OOP paradigm, and design patterns can only take you so far. (Personally, I consider the fact that we need design patterns a sign of this - if the paradigm provided these solution out-of-the-box, it would be more expressive for these problems, and the standard solutions would be obvious. There is no design pattern to describe method inheritance, because it is a core feature of OOP; but there is a Factory Pattern, because OOP does not provide an obvious natural way of constructing objects polymorphically and transparently.)
Because of this, most modern OOP languages incorporate features from other paradigms, which makes them more expressive and more powerful, but also more complex. C# is the prime example for this: it has obvious OOP roots, but features like delegates, events, type inference, variant data types, attributes, anonymous functions, lambda expressions, generics, etc., originate from other paradigms, most notably Functional Programming.