Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

Что в монге определённо не нравится (и это не моя "идея", об этом пишут даже в учебниках под монге) - это тотальная денормализация данных. Которая в некоторых случаях может сыграть злую шутку. Например, все комментарии "поста" обычно хранятся прямо в самой сущности поста. Это очень удобно и довольно быстро работает, но... иногда это приводит к полному коллапсу. Особенно, когда у Вас перекрестная ссылочность.

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

Фреймворков в целом, которые достигли должного уровня популярности и народного признания - не так уж много (если говорить о PHP-фреймворках).

Для начинающего, с целью понять сущность MVC, "пощупать" некоторые аспекты фреймворка, такие например, как загрузка библиотек и пр. подобности, я бы порекомендовал Вам CodeIgniter. Отличная документация, довольно много людей, кто сможет Вам ответить на возникающие вопросы, есть документация на русском. А так же, минимальное количество "лишнего" из коробки, например, шаблонизаторов (которые Вы можете самостоятельно подключить, если очень хочется).

После этого фреймворка, промежуточным, можно было бы считать Kohana, но, он что-то то "умирает", то снова "воскресает"... С документацией на него, по моему, всё так же плохо (читай "не очень хорошо") как и всегда... но, по нему есть несколько неплохих видео-уроков.

Суда же можно отнести Yii, на мой взгляд, он застрял где-то между "большими" и "маленькими" фреймворками. Маленьким его уже не назовёшь, по ряду признаков, а до большого и целостного - он ещё не дотягивает. Но, он довольно популярен на просторах бывшего СССР (по понятным для многих причинам), в виду чего имеет довольно большое русскоговорящее сообщество и целую толпу ярых фанатов.

Далее, в обязательном порядке будет идти Laravel - превосходная документация, примеры и фантастическое количество видео-уроков (если хорошо понимаете английский). Отличный фреймворк собранный на базе Symfony. Относится уже к "большим".

Ну а когда станете совсем матёрым программистом, и "лишний" код будет писать уже не в моготу, когда изучите все основные аспекты разработки, в том числе "сервис контейнеры", "внедрение зависимостей", будете понимать основные сетевые протоколы на низком уровне... а качество и разделяемость кода - будет одним из приоритетных условий - рекомендую обязательно ознакомиться с Symfony. Уроков по нему, довольно небольшое количество, вменяемого материала на русском языке - практически нет вообще... Но, достаточно легко изучается когда есть хороший багаж знаний и опыт работы с другими фреймворками.

P.S. Я понимаю, что Вы спрашивали "какой фреймворк учить первым?", а не какие они бывают вообще. Но, дабы предостеречь Вам от вопросов типа "какой фреймворк учить вторым?" или "почему Symfony в роли первого фреймворка так тяжело изучать?" и массы прочих подобных - озвучил одни из самых популярных фреймворков в мире веб-разработок в ракурсе PHP.

- Представление о MVC имею. Раньше писал пару проектов на CodeIgniter, но на нём на мой взгляд мало что есть из коробки, и много времени уходит на разработку.

С тех пор изобрели Composer, при должном желании прикручивается он и к CI в том числе :)

- Нужен современный не заброшенный фреймворк, с достаточным количеством документации. Не обязательно на русском, но будет плюсом.

На русском - CodeIgniter, на не русском - Laravel, Symfony и другие.

- Хотелось бы большое количество подключаемого функционала из коробки, для экономии времени разработки. Например уже написанная логика авторизации, регистрации, восстановления пароля и разграничения по уровням доступа. Понимаю что всё равно придется немного допиливать под свои нужды, но времени это сэкономило бы кучу.

Composer - решает 99% проблем, практически в любом фреймворке.

- Возможность работы с различными БД из коробки

Пока фреймворков без этой штуки не видел, но есть... Вы не поверите, Composer, что бы сменить/поставить "другой" ORM, если Вам "текущий" чем-то не подошел.

- Поддержка кэширования из коробки. И желательно что бы была поддержка некешируемых областей при генерации страницы, а сам кэш был управляемым.

То о чем Вы говорите, это: Varnish, Nginx+SSI и т.д. кэширование "из коробки" есть в Symfony (т.к. если его отключить, страницы может генерироваться феерически долго)

- Не тяжелый фреймворк, в котором оптимизирован код, и который не жрёт огромное количество ресурсов на сервере. Если будет поддержка PHP7 - тоже плюс.

По моему, любой современный фреймворк, если уже даже "Битрикс" небеизвестный до этого до этого дошел... некоторые фреймворки вообще скоро будут требовать PHP7, а не только "поддерживать".

- Проект будет ориентировочно крутиться на nginx+php5-fpm. Думаю практически все фреймворки смогут работать в этой среде, но вдруг...

Я пока таких "вдруг" не встречал. Если у админа голова и руки на месте - то никаких "вдруг" быть не должно. А вообще, у PHP версии 5.х, есть как минимум 3 основных "ветки", это <5.3, >=5.3 или 5.4+ и т.д., ещё кое-какие отличия были в 5.5 и 5.6, но не такие "разительные", подробности можно почитать в истории версий PHP. По этому, нужно конкретнее указывать версию, например, Laravel требует 5.6+

- Возможность масштабирования. В принципе не обязательно, но возможно однажды будет масштабироваться проект.

Это не возможность фреймворка - а навык программиста/админа.

- Всякие плюшки из коробки типа каптчи, обработки и обрезки изображений и прочие приятности будут огромным плюсом и будут иметь «больший вес» при выборе, т.к. важна простота и скорость разработки.

1. Yii2
2. CMS + готовые модули CMS
3. Вы не забыли, что есть... composer?!

P.S. Простота и скорость разработки зависит исключительно от уровня Вашего понимания процесса и прочих личностных навыков. В эти же навыки, как один из первичных, входит умение "правильно выбирать фреймворк под конкретную задачу".

Большое спасибо за время уделенное прочтению моего вопроса, и огромное спасибо за Ваши ответы.

Не за что! Кнопка "Мне нравиться" - сразу под сообщением :D

Давайте попробую по пунктам:

Почему (Mobile First) или (Desktop First) лучше ;
Почему (Mobile First) или (Desktop First) хуже ;

что-то из серии "Что лучше, ложка или вилка?" Ну Вы поняли... Это вопрос исключительно удобства и он напрямую зависит от того, какой у Вас исходный шаблон, и в какую сторону его проще будет адаптировать. Но даже и в этом случае, слово "лучше" тут мало уместно, скорее это вопрос удобства. Мы (в общей сложности человек 50+, от студентов до матёрых разработчиков) взяв за основу ряд параметров с отметкой "нужно делать вот так" от Google PageSpeed провели массу тестов и дискуссий... В результате которых, едино правильного подхода найдено не было. Самый удобный с точки зрения здравого смысла, был такой вариант:
1. Сначала пишем все общие стили, описывающие цвета, шрифты и всю такую ерунду
2. Для каждого диапазона разрешений создаём свой стиль-корректор, который описывает (корректирует) позиционирование элементов, их размеры, размер шрифта и т.д.

Таким образом, как Вы понимаете, "first" вообще отпадает как таковой, получается "and". Но Google'у не нравится такой подход, он просит запихивать "все важные стили" в , и отделить в таком режиме "важные стили" от "не важных" невозможно, т.к. степень "важности" определяется в зависимости от разрешения устройства. Но, говоря исключительно о личном удобстве - удобнее - начинать с мобильной версии, т.к. она априори "меньше" и расширить элемент гораздо проще, чем "слепить более мелкую его версию".

Производительность (Mobile First) или (Desktop First) ;

На производительность это в общей сложности не влияет никак, т.к. Вы банально даже JS'ы можете подгружать нужные на нужное разрешение, по этому вопрос производительности тут вообще сложно обозначить. Хотя, конечно можно опираться на такое условие как "мобильные всегда медленнее чем стационарные устройства", и из этих соображений, если такое условие "сильно вывернуть" и возвести в ранг абсолюта - тоже будет логичнее сначала делать "Mobile first".

Где и каким сайтам подходит (Mobile First) или (Desktop First) ;

MobileFirst по определению идеально подходит тем сайтам, которые изначально (в первую очередь) рассчитаны именно на мобильные устройства, например какой-нибудь "музыкальный сервис онлайн, с возможностью прослушивать MP3'шки в качестве 32-64Кбит, специально для тех у кого кончился трафик и интернет работает с ограничениями скорости". Остальное я описал выше :)