It’s not irrational - but blueprints are not the entire engine and they shouldn’t be expected to meet all needs out of the box. Blueprints are first and foremost a way to empower more people on the team to contribute to the game in a way that previously was the exclusive domain of programmers. We’ve made them powerful enough to do a great deal of stuff, but not everything is safe or efficient to do in blueprints. They are for the most part associated with a world, only recently have we begun to expose out of world classes to blueprints (Game Instance). Over time we’re trying to expose more things to blueprints when it makes sense, but sometimes you’ve gota write some C++.
Loading is just one of those things - when it’s happening, the core game loop isn’t really running, so much more care must be taken with what code is run at that time. Especially when things like multiple threads are involved. We plan to have a simpler loading screen system, but it will definitely not be a solution that solves everyone’s needs for a loading screen out of the box. Maybe the system we make just allows a movie, or a texture, some stock progress bar, or spinning icon. But if you want people to be able to play pac-man or take controller input and spin a model around while they wait, or display some tips, you’re definitely going to need to write some C++, unless you use the level streaming system.