Don't use CRTP

I don't like the boilerplate of the specialization of the state and transition list, but I cannot see how I could do it less verbose.

The problem comes from the curiously recurring template pattern. It is limited in what it can do, since at the time the base class is instantiated, the derived class is not fully defined yet. So let this idea go. Instead, don't derive CoffeeMachine from anything, but instead write FSM such that you can write this in main(), without needing any other changes there:

FSM<CoffeeMachine> fsm;

To make this actually work, some things need to happen:

Move information about the state machine into CoffeeMachine

The state map and transition list now have to go into CoffeeMachine, as there is no FSM<CoffeeMachine>. But we don't want CoffeeMachine to know too much about how FSM actually wants to store its data. The only thing CoffeeMachine knows is the list of states and the list of transitions. We can encode that using constexpr arrays. First, we need to define some helper structs though:

template<typename T>
struct FSMState {
    typename T::State state;
    bool (T::*action)() = {};
};

template<typename T>
struct FSMTransition {
    typename T::State from;
    typename T::Event event;
    typename T::State to;
    void (T::*action)() = {};
};

Now we can move the enums and the state and transition lists into CoffeeMachine:

class CoffeeMachine {
    enum class State {
        Idle,
        …
    };

    enum class Event {
        MoneyInserted,
        …
    }

    …

    static constexpr FSMState<CoffeeMachine> states[] = {
        {State::Idle, &CoffeeMachine::onIdle},
        …
    };

    static constexpr FSMTransition<CoffeeMachine> transitions[] = {
        {State::Idle, Event::CoffeeButtonPressed, State::Wait4Money},
    };

    static constexpr State initialState = State::Idle;
};

So FSMState<CoffeeMachine> and FSMTransition<CoffeeMachine> look CRTP-ish, but here it's fine.

Make FSM build the maps

Now that the states and transitions are defined in the object we want to make a finite state machine for, FSM has to turn that into something it can efficiently query at runtime. You already used a std::map for the states, which is better than a std::vector, but even better is a std::unordered_map. Similarly, each state should have a map from events to the destination state and any action that needs to be performed. You can write it like so:

template<class T>
struct FSM
{
    using State = typename T::State;
    using Event = typename T::Event;

    using EventAction = bool (T::*)();
    using TransitionAction = void (T::*)();

    struct TransitionInfo {
        State to;
        TransitionAction action{};
    };

    struct StateInfo {
        EventAction action{};
        std::unordered_map<Event, TransitionInfo> transitions;
    };

    State currentState{T::initialState};
    std::unordered_map<State, StateInfo> states;

First some using declarations (which are a better form of typedef) to simplify writing types, then some helper structs, and finally there is just one map, states, which contains for each state both its action and the possible transitions. Now we just need to fill it in at construction time:

public:
    FSM() {
        for (auto& state: T::states) {
            states[state.state].action = state.action;
        }

        for (auto& transition: T::transitions) {
            states[transition.from].transitions[transition.event] = {
                transition.to,
                transition.action
            };
        }
    }

But that's not enough, because where is the CoffeeMachine object itself?

Make FSM own a CoffeeMachine object

As there is no longer a base class and derived class that combined the state of both FSM and CoffeeMachine, FSM should now explicitly instantiate a CoffeeMachine object. And since CoffeeMachine could have a constructor, you want to be able to pass any arguments to that constructor. You can do that like so:

template<typename T>
class FSM {
    …
    T self;

public:
    template<typename... Args>
    FSM(Args&&... args): self{std::forward<Args>(args)...} {
        …
    }

Now you have all the information to step() and process() events:

    void process(const Event event)
    {
        const auto& transitions = states[currentState].transitions;

        if (auto it = transitions.find(event); it != transitions.end()) {
            std::invoke(it->second.action, self);
            currentState = it->second.to;
        }
    }

    bool step()
    {
        if (states[currentState].action) {
            return std::invoke(states[currentState].action, self);
        }

        return false;
    }
};

I used std::invoke() here to avoid the horrible member pointer syntax. With this in place, your code should work, without needing overly verbose specialization. I might have overlooked some way to have things be automatically deduced.

Note that in main() you now have to write CoffeeMachine::Event instead of Event_t, but you can just write using Event_t = CoffeeMachine::Event. Alternatively, you can keep the enum definitions outside CoffeeMachine, and just declare using Event = ::Event_t inside CoffeeMachine, although I recommend avoiding polluting the global namespace with something as generically named as Event_t.