It's mostly true. There is nothing that technically stops you from using the STL. However there are certain aspects of Unreal that make some of the more useful aspects, like the containers, less useful. The big reason is reflection.

The whole UE4 reflection system of macros is based on type declarations and it is pretty fundamental to how major portions of the engine function. You're immediately at a deficit when creating types that aren't reflected. The engine has support for their template types but that's about it. If you have engine source it's possible to extend their systems to recognize other templates, but I wouldn't recommend it. I've actually been occasionally frustrated at not being able to expose even my own template types. I have seen a couple threads on the unreal forums about this topic, it's even possible it's been part of the UE5 upgrade.

If you're writing C++, and you're writing 1) code that doesn't need to be called by blueprints or 2) you're creating data structures that also don't need to be seen by blueprint or 3) creating data structures that ever need to be serialized: then you should be able to use STL containers just fine. But you'll quickly find that those sorts of restrictions make it much harder to build a solid project.

It's really easy to think that something will never be needed by blueprint just to find out later that you do and it's usually a bigger pain to manually write the extra glue code just because your data is held in STL containers. It's easier in the case of serialization because it usually more obvious what sorts of data is only needed at runtime and won't ever need to be saved.

Ultimately you'll save yourself a lot of headaches and be able to spend time writing the interesting code if you use the tools Epic has provided to use within their engine.

Using the non-container portions of the STL shouldn't have any other problems, other than the fact that the UE4 containers don't have the same APIs as the STL ones. And many of the template functions from the library expect those to compile correctly.

Well I wouldn't recommend making that determination based on Unreal's support for the STL! ?

It's worth considering the language in general, if you already know either C# and C++ then using the one you enjoy working in will be a big benefit to staying engaged in whatever project you start. If you only know one, that's can be a strong indicator. I don't have any experience with C# or Unity, but Unreal is not the way anyone should learn C++ and I wouldn't be surprised if the same was true for Unity and C#.

I mentioned blueprint briefly and they're worth mentioning again. It's possible to write whole games using only blueprint. It's still programming, but a bit more accessible. I think Unity has something similar, or they've bought one and are going to be integrating it, or something like that. But even then you get a whole lot more out of UE4 if you can write C++.

Ultimately there are a lot of great comparisons out there on the web by folks with a lot more experience with both engines than me (or at least more experience with Unity). You either do your research to make a choice, you just pick. You can always choose the other one if it's not clicking.

Personally I'm partial to Unreal at this point, but I'm also a weirdo that I kind of like programming in C++.