Hey Maxi! 
Don’t be discouraged and keep at it. The most difficult thing about unreal is just getting used to the patterns that are at play here. I can see scenarios where too many ways to do the same thing could be frustrating but I honestly think this is a huge benefit. One thing that drives me absolutely insane in other commercial game engines is that there is generally two common things that happen during design of the engine that become obstacles in advanced scenarios.
**1**: An engine will be built in a very generalized way so that it can be used for as many possible game types/patterns as possible. This can enforce frustrating limits if feature implementations get too non-specific, usually in the form of the engine trying to do everything for you and leaving no possibility for customizing the internal details of things.
**2**: An engine will evolve from a studios successful game series and be very very tightly coupled to that games feature set and patterns. Basically you end up with an engine that was intended for use "x" but fitted to be also good for use "y" and "z".
Looking at game engine design in that way, I’m sure you can imagine a whole world of limitations that be enough to break the spirits of even the most hardened developers.
Epic, while inevitably having some tendencies from both categories above, has done a terrific job trying to avoid those pitfalls typical to other game engines within Unreal Engine 4. They are doing their best to keep the engine “game-type agnostic”, which is why you will find that there are several ways to achieve similar end-results quite often. Sometimes this will mean that there won’t be a super simple, straight forward way to do things that we view as typically simple and trivial. The upside to this is that it avoids the typical closed-implementation horrors that we find in other game engines when we want to customize how very specific things are done, or even entire systems for that matter. Of course there are certain hard-coded limitations that are imposed (typically they are things from the heart of the engine relating to reflection or auto-generated header content, etc) but I’ve noticed that Epic continually revisits these issues and is slowly removing limitations and/or adding support for more fluid design patterns. Perfect example is the improvements to c++ code support, FObjectInitializer reliance is almost completely gone, more natural syntax is slowly coming into the fold.
I’ve definitely had my moments where I wished I could just take the graphics pipeline and ditch everything else lol, but cooler heads prevail each time and I’m usually able to find an acceptable solution or workaround for problems.
As for the problems with documentation, this is just something that is going to take some patience. It’s an enormous code-base and it’s updated regularly which is making it difficult to keep up with understandably. Epic really has seemed to put improving documentation much higher on the priority list lately though and it’s showing (thanks guys and gals!). There is still some pretty important stuff that lacks documentation but if it’s something high priority for you, make use of the forums, answerhub, and don’t forget the IRC channel on freenode #unrealengine to appeal to the community. You’ll even catch some of Epic’s peeps lurking in IRC on occasion where you can get some real-time convos with them about problems with your code. Personally, I’ve found that digging through the engine source often helps me find solutions. Although I will say this to Epic in regards to documentation: Document everything in code as you go please. Everything! I know its a pain sometimes and can slow things down but even those little template methods that you might think get overlooked don’t. 
Just keep at it Maxi and don’t let those frustrations drive you away. With UE4 you are in good hands. I’ve had the engine since the end of October now, and my first 4 months I intentionally spent studying the engine’s documentation, it’s source and doing lot’s and lot’s of little experiments and tests to make sure I understand the aspects of the engine that relate to my planned project. I even discovered a way to use ALL of the scalar types (int16, uint16, uint32, uint64, etc.) within blueprints from a plugin I made that doesn’t even modify the engines source! lol The Epic Dev that noticed I had done this even seemed baffled. Just keep at it, study and be patient.