For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance. That last 5% though you are doing weird things and so need to do something manually. (as the other poster said, make_unique is implemented with new) Of course the 5% is overall. Some projects never have anything that gets into that last 5%, while others it is more like 50% of the code can't use make_*. If at all possible your use of new/delete should be limited to a data structure/container than handles it, and not scatters all over.
"For 95% of all code that is correct. std::make_* is easy to use and prevents a lot of mistakes, while having no loss of performance."
For 95% of code std::unique_ptr has no loss of performance. Perhaps. Just remember that it is not a zero-cost abstraction, the compiler won't always be able to entirely eliminate the overhead:
https://www.youtube.com/watch?v=rHIkrotSwcc
I watched that about 7 years ago when it first came out, and at an hour long I'm not about to watch it again... From what I can recall those are things that rarely are important. There is a cost, but in most real world code they only add a few nanoseconds - I have more important things to worry about.
As a firmware developer commonly operating on devices with 32MHz of cpu, i am offended sir.
If your doing firmware you probably shouldn't be doing much memory allocation at runtime anyway to prevent memory fragmentation.
Even at 32Mhz you typically have more important things to worry about. These nanoseconds are unlikely to add up - the overhead from the underlying new/delete is going to be much worse.
The unique_ptr destructor is called on scope exit, and there are times you want this earlier before other critical code.
That's why you can define your own scope to control that.
you can call release or reset as needed if you want the delete to happen early - and if you forget an obscure code path it still gets deleted on scope exit which is probably good enough for that path.