Sometimes the most important principles in software engineering are K.I.S.S and Y.A.G.N.I.
All software engineering principles, guidelines, methodologies are merely suggestions which exist to steer you down a route where you may end up with a better solution than the one which you might otherwise have written if you'd simply hammered out a solution based on the first thought that popped into your head.
DDD, CQRS, ES and others are popular for a reason - because somebody else tried the "Nike" approach of Just Do It, found themselves with a codebase resembling a Big Ball of Mud with a vast back catalogue of Technical Debt, identified the mistakes they made in their design or process, and bundled up the advice in order to help others avoid that same fate (and/or how to dig themselves out of that hole once they're already in too deep).
DDD, CQRS, ES, et-al are not Buzzwords (real developers apply them to real projects with positive results), but they are not Silver Bullets either. To understand the benefit of any methodology, guideline or principle is to understand not only how to put it into practice, but also when to follow it, and when you won't benefit from it. Some problems particularly lend themselves to particular techniques, whereas others need a different approach
To provide a concrete answer to the question "Are they worth it?" (Which I interpret to mean "should I use them right now?") would be to take a deep look at the specific project you're working on and take a judgement call for that project, based on the types of features you need to deliver (now vs in future), estimated time, complexity, budget, deadlines, etc.
The typical 'cost' of DDD/CQRS/ES is more time spent iterating on your original design and throwing away or refactoring the bits which aren't working - no doubt that even if you follow these approaches your initial implementation will include many aspects of the 'Nike'/Just-do-it solution; the key difference is how you progress after throwing together the prototype or initial solution.
As a developer, its more important to ensure your own understanding on how to apply DDD and CQRS, and how to recognise whether you're approaching your project the right way. It's likely you'll find them useful at some point, although the way to make the leap is to use them in anger (i.e. attempt to apply them to a real project and iterate your design until you feel comfortable with it).
Time spent trying new things is rarely wasted even if the process is frustrating and results in failure (Some might even say that you will learn a lot more from failure). It's absolutely worth spending your own time being persistent in learning different ways to approach different problems - frustration is a normal part of this process; it's a sign that there are things you still don't understand, but that doesn't mean they aren't worth understanding. Gaining greater knowledge and understanding is likely to lead toward becoming a "better" developer, even if you don't actually put any of that knowledge into practice on your current project or with your current employer.