C++ Implementation of a Python-like memoization decorator
Only #include public headers from the STL
You should not #include &lt;bits/stdc++.h&gt;. It is a non-standard header that is not guaranteed to exist or work as you expect it to. If you do this regularly, please unlearn this, and instead #include the proper header files. You only need two for your memoizer:
#include &lt;map&gt;
#include &lt;functional&gt;

No need for trailing return types
I see you specify trailing return types for several of the functions and lambdas you define, but I do not think they are not necessary here. The compiler can automatically deduce them, and while returning a lambda with an auto return type is not the same as when the return type is explicitly set to a std::function as mentioned by HTNW, the caller can always do this conversion themselves if necessary, and indeed that is what happens when you write dp = memoize(...) inside minDifficulty().
Consider rewriting it as a class
Instead of writing memoize() as a function that returns a mutable lambda function, I would just go for the less exciting way of writing a class. The main reason is that more people will be familiar with it, and if you ever want to add functionality to the memoizer, a class makes that much easier. Here is how it could look:
template &lt;typename RetType, typename... ArgTypes&gt;
class memoize {
    std::function&lt;RetType(ArgTypes...)&gt; func;
    std::map&lt;std::tuple&lt;ArgTypes...&gt;, RetType&gt; memo;
public:
    memoize(std::function&lt;RetType(ArgTypes...)&gt; func): func(func) {}
    auto operator()(ArgTypes... args) {
        auto key = std::make_tuple(args...);
        if (auto it = memo.find(key); it != memo.end()) {
            return it-&gt;second;
        }
        auto [it, emplaced] = memo.emplace(key, func(args...));
        return it-&gt;second;
    };
};

This is actually a complete drop-in replacement for the lambda, even this line will still work:
dp = memoize(dp);

Use in production code
Your memoizer could be used in production code, sure! However, apart from coding challenges I've found the number of cases where I would ever need this to be vanishingly small. Either things need to be remembered much longer than the lifetime of a program, in which case a proper database is used, or all the values you could probably want are precomputed once and included with the binary, or the algorithm I am implementing would be just as easy to implement by reading/writing to a container directly instead of using a memoizer function.
A std::map or std::unordered_map is also not always the most efficient way to store things, often a std::vector is much more efficient if the function just gets a single integer argument. And your memoizer also doesn't handle the case where some parameters to the function are not part of the key to be memoized, although you could work around that by using std::bind() or some other form of currying.
In short, there's nothing wrong with it as far as I can see, but I think there won't be very many occasions where you would need it.