R>Когда сталкиваюсь с задачей, которая не выглядит специфичной для этого конкретного проекта, ни в коем случае не делаю своё решение, а ищу подходящую библиотеку/фреймворк. Без исключений.
R>Объясните популярно почему я неправ,

Потому что ты перечислил плюсы использования библиотек, но проигнорировал минусы.

Навскидку еще один из минусов: ты портируешь свою программу в другую среду или другую версию ОС, или просто для работы в другом окружении — а библиотека, сцука такая, под эту новую среду не собирается/не работает. Даже та функция, которую ты оттуда использовал, прекрасно работала бы. Но в библиотеке содержится еще другая функция, которая тебе нафиг не уперлась, но которая обламывает сборку или корректную работу библиотеки.

R>и как нужно делать на самом деле.

А универсального решения тут нет. В каждом конкретном случае нужно думать головой и прикидывать, а стоит ли овчинка выделки

Попробую я объяснить, т.к. у меня тоже когда-то было такое мнение.

Итак, нужно добавить в проект новую фичу Х.

Сначала определяется, знаю ли я, как её реализовать. На этой фазе срезается большинство неопытных разработчиков, т.к. они просто не имеют достаточно знаний/опыта, чтобы написать велосипед.
Затем, хочу ли я это знать и готов ли я это велосипедить. Если речь идет о сложной и/или формализованной области а-ля парсинг урлов, сжатие/шифрование или видеокодеки, то, конечно, лучше брать готовую библиотеку.
В сухом остатке остаются фичи, которые я знаю, как реализовывать, и теперь нужно выбрать библиотеку или велосипед.

Готовая библиотека, конечно, лучше, если:
— её поиск, изучение, тестирование и добавление в проект будет быстрее, чем написать свою реализацию. Это к вопросу о leftpad.
— она не содержит ошибок. Не нужно считать авторов библиотеки безгрешными, особенно, если у неё нет массовой аудитории.
— она будет работать в вашей среде. Например, 95% библиотек с кучей звезд не пригодны для хайлоада, т.к. пожертвовали быстродействием ради удобства использования или какого-то упрощения.
— она не слишком интрузивна, т.е. не заставляет использовать свой код пятнами по всему проекту. Привет логгированию, AOP и фреймворкам.
— вы понимаете, какой функционал получаете в нагрузку к нужному вам. Это к вопросу о дырах в безопасности(XML), непредсказуемому поведению программы(хибернейт), излишнему расходу цпу и памяти.
— вы готовы вешать на проект дополнительные сущности. Велосипед решает конкретную задачу, библиотека добавляет абстракции, которые пригодны для решения задач большинства. Пример — библиотеки валидации
— её исходники достаточно понятны и документированы, чтобы понять, почему она ведет себя не ожидаемым образом и как правильно.
— её можно будет заменить малой кровью, когда автора переедет автобус, появятся не вписывающиеся в неё требования или конфликт при миграции на новую версию чего-нибудь.

Мораль: хорошая библиотека имеет компактный API, массово используется, оптимизирована, документирована, решает одну конкретную задачу.
Вывод: хороших библиотек очень мало.