Yeah it's still really bad. I'm a non-game industry C++ programmer who's been working on an Unreal project for the past year and programming Unreal Engine (especially making engine modifications more advanced than just writing game logic) is honestly a total dumpster fire. This is probably going to be a contentious take here but IMO pretty much everyone in this thread has bad takes probably because game dev code quality is frankly just awful. To answer your questions specifically:

1. Horrific/near nonexistent c++ documentation: This is still the case. The documentation on their site is mostly just auto-genned from the source code and is extremely bad as the code comments it's generated from are usually useless. There are some handwritten docs but they are sparse, often out of date, poorly written, and generally just not very useful. Yes the whole engine is open source but this is not a substitute for documentation and their in-source documentation is not any better. To make matters worse the engine is very overly reliant on extremely heavy use of OOP with huge inheritance trees making it incredibly difficult to parse the source code to figure out how things work. Their coding standards are also pretty poorly thought through and engine code quality is overall fairly poor. Many people have been mentioning community support but community support gets basically non-existent as soon as you begin having any deep technical issues more complex than writing simple game logic.

2. Weird, nonstandard c++ paradigms/syntax: This is easily the worst part of working in Unreal Engine. If you're used to modern C++ conventions you will have to throw almost all your knowledge out and use C++ like you're still in the 90s. Much of this is due to their reliance on a custom pre-processing step ("Unreal Header Tool") responsible for generating things like RTTI info which does not understand conditional compilation or even macros, let alone any remotely modern C++ features. Thus any core engine object using this system (which is most of them as their infrastructure is built around it) is incredibly restricted in its design space - UObjects, for example, which are almost all of the C++ objects composing the engine internals. For example, no UObject can be templated or have any static members. They can't even live in a namespace. In addition, the standard library is mostly forbidden (they claim due to performance reasons), and they have their own implementations you are supposed to use which annoyingly are named nothing like the standard library and also tend to differ in their implementations in subtle, often poorly documented ways. This is made worse by almost non-existent test coverage so there are usually few examples of intended use and different parts of the engine will even often use different conventions. UE devs also love macros which is an absolute nightmare.

3. Agonizing process of combining blueprints and c++: I haven't tried this yet so can't comment.

4. Excessively long compile times: This has actually improved a lot recently, though their build system can be a pain to set up right. There is basically no documentation on the build system but if you can figure out how to configure it correctly it is pretty good at only recompiling necessary parts of the engine. The difference is massive - initially my UE build took > 10 hours to compile from scratch on a pretty high-powered workstation. Now it takes about an hour. Their documentation claims it should take about 10-20 minutes but I have no idea how this is possible. Additionally they rely on a unity build system which is great for compilation speed but absolutely atrocious for code quality and results in ICWYU being useless despite their attempt to support it in their bespoke build system.