Includes

I like the consistent use of alphabetical order for standard library includes. This makes it much easier to quickly check for missing includes.

main.cpp:

• <iostream> is documented to include <ios>, so we're able to omit the latter.

menu.h:

• If we move the definition of noop() to the implementation file (or remove it entirely - see later), we'd be able to use the much lighter <iosfwd> instead of <iostream>.

menu.cpp:

• Missing an include of <cctype> (but see later recommendation to use <locale>).

read_double()

The interface is restrictive, in that it requires construction of a std::string. Consider accepting std::string_view instead - this can reduce unnecessary copying of contents.

It's good that this function re-asks if conversion was unsuccessful. Unfortunately, it doesn't treat end of file as an unsuccessful case, so we get an infinite loop if std::cin is closed. One way to avoid that would be for our main() to set the stream to throw at eof:

int main()
{
    std::cin.exceptions(std::cin.eofbit);
    try {
        ⋮
    } catch (std::exception& e) {
        std::cerr << e.what() << '\n';
        return EXIT_FAILURE;   // include <cstdlib> for definition
    }
    std::cout << "Good bye!\n";
}

Instead of the success local variable, we could use an infinite loop, and return from the success branch:

    for (;;) {
        std::cout << prompt << std::flush;
        if (double number;  std::cin >> number) {
            return number;
        } else {
            ⋮
        }
    }

In the else block, when we ignore rest of line, we should be calling our clear_console_input() function rather than writing it out again.

The usage message ought to go to std::cerr rather than std::cout.

read_operands_div()

Rejecting division by zero shouldn't be necessary on most platforms, as floating point formats pretty much all support infinities. If we want to be truly rigorous, we could test for this:

std::pair<double, double> read_operands_div() {
    if constexpr (std::numeric_limits<double>::has_infinity) {
        return read_operands();
    }
    ⋮
}

add()/subtract()/multiply()/divide()

These functions differ only in two places. It would be better to have a common function they can all use, rather than writing the same code again and again (and having to keep them all in sync forever).

static void binary_op(std::string_view name,
                      std::pair<double, double> operands,
                      double result)
{
    std::cout << "Result of "
              << operands.first << ' ' << name << ' ' << operands.second
              << " is " << result << std::endl;
}

void add() {
    auto numbers = read_operands();
    binary_op("+", numbers, numbers.first + numbers.second);
}

void subtract() {
    auto numbers = read_operands();
    binary_op("-", numbers, numbers.first - numbers.second);
}

void multiply() {
    auto numbers = read_operands();
    binary_op("*", numbers, numbers.first * numbers.second);
}

void divide() {
    auto numbers = read_operands_div();
    binary_op("/", numbers, numbers.first / numbers.second);
}

main()

Not much to say here. We don't need to return 0; at the end of main() - if we omit that, C++ infers it for us.

menu_item

explicit constructor - good!

We copy into member title - better to pass by value and std::move() the value into member. We can combine the two constructors using a default argument:

    explicit menu_item(std::string title, std::function<void()> action = &noop)
        : title{std::move(title)},
          action{std::move(action)}
    {}

That said, I don't think there's any valid use case for defaulting the action - I would completely remove noop() and always require the action to be specified.

The copy constructor is identical to what we'd get if we defined it = default. So just omit that, and it will be provided without any source code.

The message emitted by noop() looks like an error message to me, so should go to std::cerr. But as I already said, better to just remove this function.

menu

Constructors

Constructors should std::move() values into members rather than copying, just as in menu_item.

Again, they can be consolidated down to just a couple of constructors by defaulting the "items" argument.

public:
    explicit menu(std::string title,
                  std::vector<menu_item> items = {});
    menu(std::string title,
         std::string description,
         std::vector<menu_item> items = {});

menu::menu(std::string title,
           std::vector<menu_item> items)
    : title{std::move(title)},
      items{std::move(items)}
{}

menu::menu(std::string title, std::string description, std::vector<menu_item> items)
    : title{std::move(title)},
      description{std::move(description)},
      items{std::move(items)}
{}

It's strange that we can assign the title and description (with no validation of any kind), but cannot read them. It suggests these members ought to be declared public.

I don't like the global nesting_level. Why isn't this a property of each menu? That would be better for separate testing, for example.

The various add_item() functions repeat their logic. I'd expect the title+action versions to construct an item and call the other overload. Actually, in this case it would be better for these overloads to construct the items in-place in the vector:

void menu::add_item(menu_item item)
{
    items.push_back(std::move(item));
}

void menu::add_item(std::string title, std::function<void()> action) {
    items.emplace_back(std::move(title), std::move(action));
}

void menu::add_item_at(int index, menu_item item) {
    check_index(index);
    items.insert(items.begin() + index, std::move(item));
}

void menu::add_item_at(int index, std::string title,
                       std::function<void()> action) {
    check_index(index);
    items.emplace(items.begin() + index, std::move(title), std::move(action));
}

The add_submenu() family pass the submenu by reference, eventually capturing that reference in a function object. But there's nothing to ensure that the reference is still valid at the time the function object is invoked.

To demonstrate, if I change main() like this:

    {
        menu menu2{"test"};
        app.add_submenu(menu2);
    }
    app.loop();

then we have undefined behaviour when that item is selected. This is a serious bug which needs addressing.

In loop(), there's no obvious need to flush output before writing the description. Rather than those std::endl, I recommend using plain newlines, with std::flush at well-chosen points. Mostly we don't even need that, because reading from std::cin will flush a related output stream.

Again, instead of bool active, we can just return where we set it false.

The indexed loop in print_choices() would be better as a range-based for:

#include <ranges>

    for (auto const& [i, item]: items | std::views::enumerate) {
        std::cout << i << ") " << item << '\n';
    }
    std::cout << "q) "
              << (nesting_level > 1 ? "Back" : "Quit")
              << '\n';

read_choice() doesn't allow entry of any choice greater than 9, though these choices are offered by print_choices(). This is a serious bug which needs addressing.

Here's a suggested replacement that addresses this bug, and also handles end of file gracefully:

#include <sstream>
std::size_t menu::read_choice() const
{
    std::cout << "What do you want to do?\n";
    for (;;) {
        print_choices();
        std::cout << "Your choice: ";
        std::string user_input;
        if (std::getline(std::cin, user_input).fail()) {
            return quit_choice;
        }
        if (user_input.size() == 1 && std::tolower(user_input.at(0)) == 'q') {
            return quit_choice;
        }
        if (std::size_t index;  std::istringstream{user_input} >> index && index < items.size()) {
            return index;
        }
        std::cout << "Please enter a valid choice.\n";
        continue;
    }
}

Note that this now returns an actual index rather than a character, so we need some other changes:

static constexpr std::size_t quit_choice = -1uz;

        auto choice = read_choice();
        if (choice == quit_choice) {
            --nesting_level;
            return;
        } else {
            std::cout << '\n';
            // call function bound to menu item
            items[choice].action();
        }

The use of std::tolower() here could be replaced with using the locale's tolower(), to match user expectations:

#include <locale>

        std::tolower(user_input.at(0), std::locale{})

check_index() has a bug when the menu is empty, because this unsigned subtraction can wrap around:

   const std::size_t max_allowed_idx = items.size() - 2;

A safer test would be

    if (index + 1 >= items.size()) {

However, this function is already problematical, because we can insert after the last element, but can't remove there. Really we need separate tests:

void menu::check_index_for_remove(std::size_t index) const {
    if (items.empty()) {
        std::ostringstream oss;
        oss << "Attempt to remove index " << index << " from empty menu";
        throw std::out_of_range{oss.str()};
    }
    if (index >= items.size()) {
        std::ostringstream oss;
        oss << "invalid index " << index
            << " for remove; must be less than " << items.size();
        throw std::out_of_range{oss.str()};
    }
}
void menu::check_index_for_insert(std::size_t index) const {
    if (index > items.size()) {
        std::ostringstream oss;
        oss << "invalid index " << index
            << " for insert; must be less than " << items.size() + 1;
        throw std::out_of_range{oss.str()};
    }
}

I also fixed the bug here where the message claimed that the (invalid) index value was the minimum (leading to nonsense such as index value must be between 4 and 2).

Some code simplifications

Your read_double function can be simplified through use of the comma operator:

double read_double(const std::string& prompt = "Enter the number: ") {
    double number;
    while (std::cout << prompt, !(std::cin >> number)) {
        std::cin.clear();
        std::cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n');
        std::cout << "Error: not a number." << std::endl;
    }
    return number;
}

Your menu::loop function can be simplified through the use of break:

void menu::loop() const {
    ++nesting_level;
    for (;;) {
        print_title(title);
        if (!description.empty()) {
            std::cout
                << std::endl
                << description
                << std::endl; // You can also avoid repeating std::cout here
        }
        char choice = read_choice();
        if (choice == quit_choice) {
            --nesting_level;
            break;
        }
        std::cout << '\n';
        // call function bound to menu item
        items[choice - '0'].action();
        // wait until user press the enter key
        std::cout << "\nPress enter to continue...\n";
        std::cin.get();
    }
}

Same goes for menu::read_choice, in that you can use an unconditional loop and then use break as needed instead of setting a flag and then immediately checking the flag in the loop condition.

The following could also be simplified through the use of the ternary conditional operator:

std::cout << "q) ";
if (nesting_level > 1)
    std::cout << "Back";
else
    std::cout << "Quit";
std::cout << std::endl;

Could be:

// Spread out over multiple lines so still readable
std::cout
    << "q) "
    << (nesting_level > 1 ? "Back" : "Quit")
    << std::endl;

The testing is insufficient. There are no tests for

    void add_item_at(int index, const menu_item& item);
    void add_item_at(int index, const std::string& title_val, std::function<void()> action);

The reason I am concerned about this is because the add_item_at() functions call check_index(). Check index can throw an exception, but there is no code in the program at all that contains a try {} catch {} block. If the check_index() function actually finds a value out of range the program will abnormally terminate. This is not a good practice.