Please, don’t get me wrong: I’m all up to giving all the power I can to artists and designers - where it makes sense. That’s one of reasones why I prefer Unreal over different engines.
Also: where actually Unity uses C#/C++ besides of “C# nativization” for packaged game? (Perhaps I’m simply not aware of something)
The thing is “artists writing chaotic code without carefully thinking about systems” (because that’s what most artists would do) isn’t something we would desire in the first place.
The goal of hiring a person called “programmer” is to design performant systems, write is easy to #mantain and “future-proof”. And it doesn’t matter is programming language is C++, Blueprints or Lego bricks.
Artists (and lot of designers) love to write quick and messy scripts, repeat lot of code, make it difficult to understand and mantain.
- No, simple conversion of “artist script” to “programmer language” won’t usually save you time. Often you need write this code differently in order to make it clean, usable and perfomant.
- “For instance spawning 100’s of units on screen with C++ is much more performant than doing it in BP”. AFAIK Calling C++ methods from blueprints doesn’t cost much more than calling it in C++. Performance usually suffer because of the way the script is done.
- If given artist/designer is “technical” - understand how things in engine works, how to properly separate data from logic (which is so easy to mix in BP) and how to organize code… he’s already a programmer.
- UE4 gives you this incredible opportunity to read and change engine code as you wish. This boost any “implementing person”, allows to learn engine better, debug complex issues faster, truly understand method he’s using.
I’d advise anybody to think often if doing something in blueprint or leaving it to “blueprint people” is actually cheaper… Time of “making feature simply work” isn’t the only or even the most important factor here. Actually sticking to blueprints could lead to bad situation of “being locked to blueprints”. Example: you can’t implement custom editors - i.e. based on behavior trees.
Or custom dialogue plugin (based on Dialogue Plugin) which I also used as “screenplay editor” in one game - working on such editor in C++ is as easy as blueprint scripting. Allows to do things impossible in blueprints, i.e. analyzing all nodes in tree. And that allows me to pre-load assets (this is huge gain!), simplify some actions, properly separate assets from logic.
Seriously, once you learn write blueprints really well and you get understanding of algorithms, object-oriented programming, systems of UE4 and principles of writing features that are easy to use for other people - jumping into C++ doesn’t seem to be rocket science anymore.
The best way to save money is to hire programmers and technical designers/artists who understand how to designs systems and tools which would be easy to use by the rest of team. This is what helps the most. It will often take longer to prototype sth, but the savings will be much bigger.
And I’m saying this from perspective of person which started as QA, moved to be “quest designer” (used special quest editor, some scripting and all the engine tools to implement game) in AAA company, then moved to be “gameplay designer” in indie space (which requires scripting, Kismet/Blueprints) and then voluntarily moved to C++ (still a designer, but technical one) what allows me to write better systems.
At some point you don’t want a faster horse (non-technical people creating blueprint spaghetti), you want to get a C++ car. ~ Henry Ford 
…