It’s already been said here but, you used a term that I’m not sure was addressed, there’s a 3rd option.
You compared Blueprints to Source code, but that’s not the right comparison.
To build the engine from source code, you download it from git, build and update the engine code yourself. Otherwise, you use the launcher and let it install the engine for you, you then only modify your project content.
If you need core features that the engine doesn’t provide, make changes to the engine, or want the latest features before they make it to the launcher, then download and build the source from github. Otherwise, if you don’t want to deal with updating the engine code yourself just get it from the launcher.
In either case, from source, or the launcher you then have the choice of either Blueprints alone for gameplay features or Blueprints and C++. I guess you could, but it doesn’t make too much since to have no Blueprints at all. That C++ is not engine source though, it’s gameplay code.
You can always add C++ to a project that is started from Blueprints. There will be some things that just require C++, and it’s recommended that code that is called every tick is put in C++. A class can have some of your functions in C++, then on a child Blueprint class can have other functions that are just in Blueprints. They can call each other, C++ calling Blueprint events and Blueprints can implement C++ function declarations, or override them. It is set up through the UFUNCTION macro declarations.
Blueprints make working with Assets much easier. It’s fairly straight forward to migrate Blueprint scripts into C++. I do it in pieces. First I decompose the blueprint messy prototype into small Blueprint functions, I then make the skeleton in C++ that calls the functions in Blueprints, testing that it still works. I then replace the Blueprint functions with C++ functions one by one ensuring the whole time that the thing is still working.
Maybe longer answer than you wanted, but, think it may be helpful as I see this type of question a lot.