Animation blueprint (which is mostly for locomotion) is well blueprint. Animation montages can be and mostly should be called from C++.
Yeah Animations, Materials and a few other things are typically almost entirely controlled/setup within special editor classes and have their own built-in toolsets for working with them. You can move some stuff into CPP to skip the Blueprint VM but I don’t think the node-based stuff has a suitable CPP interface to work with.
It’s easy to make C++ functions that are callable from Blueprints and Blueprint functions that are callable from C++. You don’t have to use only Blueprints, but for most stuff dealing with assets it’s convenient to have Blueprint layer
I wouldn’t say its easy especially for someone that learned the entire engine and c++ in 3 days… But I already figured that out and am calling animations with BlueprintImplementableEvent linked to Play Animation. Things are going pretty good just some annoying things like the engine crashing randomly when I build my VS project even when the code is sound and my scaling options in editor preferences getting set to default and not being able to disable the right click menu and when opening project it opens all the folders in the world outliner and getting reference errors when deleting assets then having to go into explorer delete it manually and restart the engine and having to change the bone names in my animated assets to prevent them from being played at 1:100 the scale but I can put up with that stuff.
If editor is crashing randomly, 99.9% times it’s your fault. Most likely, you didn’t notice some error in your code (dereferencing nullptr, calling out of bounds array element, etc)
However, if engine could break on erroneous line instead of crashing, you can easily figure out all the issues that cause crashing. And it’s possible, you can install Debug Symbols in Epic Games Launcher. I assumed you still didn’t - then go, it’s really useful when working with C++.
I literally just said the code is sound… Editor restarts after crashing then works fine… I’m not doing anything too advanced 3 days in. Tonight was the worst bug tho while working on a door blueprint and hitting play it crashed again. Crashed about 40 more times only giving exception 000000000x errors while I tried to figure out the problem. Ended up deleting my player blueprint which resolved the crashing yet was not linked at all to the door blueprint which is what I was working on, yet it was playing fine before…
But you spout off some garbage about it being 99% your fault… think again
Frankly in my experience it almost always is, even if you don’t initially understand why.
Think of it like this - the more “basic” or “common” areas of the UE codebase have been somewhat exhaustively used and tested by millions of developers at this point, and for that reason they are pretty much always stable. If something is happening at the Actor / Component level for example - you can be confident that you messed up somewhere, or did something the engine didn’t expect/want you to do.
Genuine engine crashes, I find at least, tend to happen in much lower-level areas of the engine that only Epic tend to touch - so deep in the renderer or physics code for example. Sometimes it might be something you did that causes it to get there, other times it might be a genuine engine bug. I find that the latter is pretty rare these days, but it definitely does happen.
If you do encounter something, it’s best to check the forum, answerhub and github to see if anybody else has mentioned it yet. This happens a lot especially when we get new major releases, and something slipped past QA. I’m not saying the engine is free of bugs (obviously it’s not, they’re a fact of software development) - but if your routinely crashing in a very common engine area, you can pretty much always rule the fault down to your code somewhere at this point.
For a more extreme example, I remember a thread from a few months ago where somebody claimed that the FVector type must be broken. The chances of that are (and were) practically zero.
You can’t learn the entire engine and c++ in 3 days, its silly to say that 
Anyway you mentioned deleting assets and having crashes after that, getting 000000x errors and similar - you are accessing null data hence the crashes.
I’ve experienced the same frustration initially. Now I make changes to the engine with good results when needed. It is still possible to mess things up in a way that cannot easily be recovered (at least not by anyone who doesn’t have even deeper knowledge of not just the engine but how the components are built and linked).
Basically there is no way around these problems. They found a balance between not compromising C++'s speed, and trying to achieve some sort of user friendliness. I think they picked the right balance but only given the assumption that you should have both (more a commercial consideration than technical). On top of that they added the ability to recompile modules on the fly.
You cannot expect the engine to be as smooth to operate as some dumbed down C# based toolset. It’s doing too much work in the background to take what you add and repackage it so that it runs as native C++ code without making everything slower. At the end of the day if you are in gamedev you are after asset complexity and frame rates, that’s all that matters. So I just recommend sticking with it. It’s super undocumented but once you chill and take the time to study how the components fit together it’s actually well thought out.