Не увидел - где же это там *не рекомендуют* не использовать -fomit-frame-pointer для AMD64...
Хотел бы немного пояснить ситуацию с OFP.
Удаление ассемблерного кода (в некоторых, но не во всех, функциях) для создания кадра стека (того самого, что учебники называют прологом и эпилогом функции, и выглядит "push %ebp" и "mov %esp,%ebp" с последующим возвратом стековых регистров на место, или же "enter" и "leave") создаст трудности при отладке (и при посылке багрепортов) программ на некоторых платформах. Например x86 (отладчик просто будет не в состоянии развернуть стек из-за отсутствия этих самых стековых кадров). О чём честно и сказано по вышеприведённой ссылке. К сожалению не знаю деталей, но, подозреваю, что на AMD64 (и, наверное, других архитектурах, навроде PPC и т.д.) используется несколько другой механизм при вызове функций, благодаря приятному наличию дополнительных регистров, - потому указание OFP на этой платформе никак не сказывается на отладке программ. И именно по этой причине любой из параметров оптимизации -O автоматически включает OFP при march=k8 и т.д..
Итак, отсутствие кода, создающего, кадры может незначительно (несколько байтов,.. может быть даже килобайтов в очень больших программах) уменьшить размер приложения (и, в большинстве случаев, увеличить её скорость работы) на x86, отнять возможность посылать полезные багрепорты разработчикам (чтобы послать репорт - нужно будет убедиться, что падение приложения стабильно воспроизводится, пересобрать его без влага OFP, воспроизвести падение и тлько затем послать багрепорт с дампом стека). Из чего следует, что для непрограммистов (да и для многих программистов) и людей, которые, не озабочены тестированием и посылкой разработчикам сообщений об ошибках, наличие -fomit-frame-pointer будет лишь на руку. И уж тем более это никак не скажется на стабильности и сборке программы.
Тут получается, все запрещено, что не разрешено