Reading these I'm struck by the non-orthogonality and "mental compilation" on display here. In Python instead of

    return numbers.end()
           != std::find_if(numbers.begin(), numbers.end(),
                           [](int number) { return number % 2 == 1; });

I would write

    return any(number % 2 == 1 for number in numbers)

which, similarly, stops examining numbers once it finds an odd one, but works by transforming the sequence of numbers into a lazy sequence of booleans, then applying the generic boolean-sequence-reducer `any` to it. I think this more clearly says what is desired (the C++ version strikes me as something a compiler might output given the Python version, but in this case you had to run the compiler in your mind), and additionally is a better orthogonal decomposition of the problem than computing a first-hit iterator from a sequence of numbers and a number-to-boolean transformation, then comparing it against the end of the sequence.

Sandor's suggested replacement solves the first problem of clearly saying what is desired:

    return std::any_of(numbers.begin(), numbers.end(),
                       [](int number) { return number % 2 == 1; });

But the penalty is even worse orthogonality!

Because of Python's better orthogonality, you can factor out the lazy boolean sequence generator into a function of its own if that's a useful thing to do:

    def oddnesses(numbers):
        return (number % 2 == 1 for number in numbers)

    return any(oddnesses(numbers))

In this particular case the extra degree of composability you get from it is not very useful, but then again, neither is the original code. You could do things like this with that sequence with equal plausibility to the original code:

    all(oddnesses(numbers))  # addressed by all_of in OP
    zip(numbers, oddnesses(numbers))
    sum(oddnesses(numbers))  # punning booleans as ints
    sum(map(operator.mul, numbers, oddnesses(numbers)))

Of course, Python is not really a viable alternative to C++ in most of the places where people are using C++, mostly because it uses 40 times as much CPU and energy and 10 times as much memory, but also because large Python codebases get unmaintainable.

But we could wish for a language with the efficiency and in-the-large maintainability of C++ and the clarity and generality of Python.