That’s also partly true. A lot of what isn’t exposed to BPs directly seems to get exposed by (and then later committed to the master branch) or others doing similar work.
The big thing right now, as mentioned, is file I/O. Dynamic meshes aren’t really something every game will need or want, but it’s difficult for me to conceive of a game (more complex than a two-button mobile game) that won’t want a Settings menu, for creating gamewide changes to config .inis (especially for input remapping, and for in-game options which don’t directly relate to Epic’s native engine scaling stuff like difficulty, volume mixes, etc) which can’t be done without C++ since writing .ini files is not exposed to BP directly.
There’s also some stuff that might frustrate you WRT not being able to change or modify default components of classes; for example, NavModifiers can be made Movable in C++ but in BP that functionality isn’t exposed on the default component so BP-only projects are stuck with Static NavModifiers only. There are also some edge-case-style things with the CharacterMovementComponent (setting minimum movement speeds and making the player up vector not be hardcoded to Z=1 are some examples from around the forums).
The good news is that every version of the engine seems to be closing that gap, to the point where it’s not difficult to conceive of a version of UE where BPs can literally do everything C++ can (though there are still efficiency concerns).