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

Такая точка зрения, несмотря на всю свою смехотворность, достаточно распространена среди далеких от программирования людей (секретарш, бухгалтеров, не ИТ-специалистов, руководителей организаций не связанных с программированием). И эту точку зрения достаточно сложно победить. Многие люди считают, что Майкрософт и так "качает" персональные и конфиденциальные данные с компьютеров рядовых пользователей.
Но, будучи администратором UNIX-маршрутизатора достаточно долгое время, я собрал некоторые статистические данные по входящему и, главное, исходящему трафику с Windows-машин. Да, действительно, трафик на IP адреса принадлежащие Майкрософт, но практически все - это трафик Windows Update, при этом мною обнаружен также неисследованный мною неопознанный трафик, но объемы передаваемых данных ничтожны (в рассмотрении на всю подсеть), рискну предположить, что это служебный трафик, но оставлю эту проблему на исследование коллегам.
Люди, более или менее знакомые с .NET понимают преимущества управляемого кода. Но вашему начальнику (либо человеку, влияющему на решение о введение новой технологии), достаточно знать следующее:

Управляемый код позволяет среде выполнения (CLR) контролировать выполнение непосредственно приложения в рамках установленной политики безопасности.

Перед выполнением, управляемый код проходит специальную проверку* (verification) на наличие контроля типов данных. Контроль типов обеспечивает дополнительную защиту данных, устойчивую работу и корректное взаимодействие с другими приложениями.

Управляемые данные, связанные с управляемым кодом - это данные, память под которые выделяется средой. При этом среда отслеживает освобождение ресурсов и самостоятельно проводит сборку мусора (garbage collection).

* В принципе возможно установить такую политику безопасности, при которой будет разрешен запуск кода без проверки. Но я не рекомендую этого делать.

Пользуясь случаем, отправляю программистов к книге Майкл Ховард, Дэвид Лебланк, "Защищенный код", Русская редакция, 2004. Я настоятельно рекомендую эту книгу всем, независимо от языка или платформы на котором вы пишите свои программы.

Заблуждение второе. ASP .NET не позволяет контролировать HTML код
Как известно почти каждому, кто хотя бы раз пробовал "поиграть" с ASP.NET, для серверных элементов управления код генерируется на лету средой выполнения. При этом разработчик не может никак повлиять на то, что будет отправлено в броузер клиенту.

Да, возможно в этом есть некоторый минус. Но, стоит взглянуть с другой стороны - разработчик избавлен от необходимости руками прописывать десятки или даже сотни строк рутинного HTML кода. Обратите внимание, вряд ли вам захочется когда-нибудь изменять сгенерированный код, тем более, что он вполне соответствует стандарту и не нарушает кросс-броузерной совместимости.
Некоторых программистов, привыкших видеть в броузере именно то, что они написали в программе, несколько оскорбляет тот факт, что ASP.NET имеет несколько иное "представление" кода во время разработки, нежели во время выполнения. Рассмотрим пример:

<asp:hyperlink id="HyperLink1" style="Z-INDEX: 101; LEFT: 128px; POSITION: absolute; TOP: 176px"
runat="server" navigateurl="http://localhost" height="16px" width="64px">HyperLink</asp:hyperlink>
Преобразуется в:

<a id="HyperLink1" href="http://localhost"
style="height:16px;width:64px;Z-INDEX: 101; LEFT: 128px; POSITION: absolute; TOP: 176px">
HyperLink</a>
Но это уже проблема связанная с личным вкусом разработчика. Дело в том, что ASP.NET позволяет упростить и ускорить разработку программ для Web, при этом приходится использовать собственное "обозначение" контролов, позволяющее среде определить, чего же именно хочет программист.

Заблуждение третье. ASP.NET генерирует код не соответствующий спецификации
Человека, посетившего сайт консорциума W3C (www.w3c.org), начинает терзать смутное желание проверить свой сайт на "совместимость" со спецификацией HTML. Вот после таких опытов использования HTML Validator и появилось ошибочное мнение, что ASP.NET злостно нарушает спецификацию.

Да, опять нельзя спорить с фактом - странички действительно не пройдут проверку, а Validator выдаст гору ошибок. Но на это у меня есть три ответа:

Во многом код страницы зависит от разработчика (многое все-таки можно поменять, даже НУЖНО менять, если вы создаете действительно профессиональный сайт.

Попробуйте в сети проверить несколько общепризнанных профессиональных сайтов и найти среди них полностью соответствующие спецификации. Даже больше - много ли сайтов пройдут проверку? Попробуйте на досуге найти хотя бы десяток (чур не пользоваться специальным каталогом!) Несмотря на то, что Perl и PHP позволяют контролировать каждый символ текста страницы. Но кто этим пользуется...

И, главное, покажите мне популярный броузер, который полностью следует спецификации?*

* Не особо я верю в Opera. Хотя, если кто-то докажет мне обратное - я буду только рад и благодарен за образование.

Таким образом, следование "букве спецификации" похвально, но не обязательно (в разумных пределах), да и придерживаясь рамок легко оказаться в клетке. Поэтому незначительное отступление от предлагаемых W3C правил оформления страниц не смертельно..

"Проект готов, ну и?" Или заблуждение номер четыре
Наконец-то проект готов. Отлажен и протестирован. Программа настолько замечательная, что ее просто обязан иметь каждый пользователь персонального компьютера. Но, вот незадача, на компьютере пользователя не установлены необходимые библиотеки, а программа не работает без них (странно, не правда ли?). Приходится создавать дистрибутив, включая все компоненты в инсталляционный пакет.
Вот тут-то и кроется очередная проблема с пониманием конечным пользователем. Почему-то пользователь предпочитает установить несколько десятков сомнительных библиотек для разных программ, чем один .NET Framework (который, кстати, включен во все ОС нового поколения) для большого числа программ. А разработчик ломает голову над тем, как заставить пользователя установить 20 Мб "ненужных" ему библиотек. Однако, при достаточно больших размерах дистрибутивов (обычно распространяемых на компакт дисках или по высокоскоростным каналам Интернет), лишние 20 Мб не такая уж и проблема. Сейчас не те времена, когда приходилось неделями писать функцию, реализованному в сторонней библиотеке, чтобы не таскать за собой лишние 300-400Кб "ненужностей".

Опять ООП? Или заблуждение пятое
Последнее заблуждение из встречаемых достаточно часто для включения в статью, уже точно вызовет улыбку у любого более или менее профессионального программиста (если он уже не скатился под стол, представляя серьезность людей убежденных в первых четырех пунктах).
Заключается оно в неприятии концепции объектно-ориентированного программирования, в том виде, в котором оно представлено в .NET. Версию того, что ООП - абсолютное вселенское зло предлагают программисты на Visual Basic 6 и более ранних версий. При этом они строго убеждены, что возможности наследования, переопределения свойств и методов родителя это шаг назад и излишнее (ненужное) усложнение (лично я не понимаю этой точки зрения и не приемлю). Основной аргумент - ядро практически любой ОС пишутся на практически полностью на C, не поддерживающем объектов. При этом С - один из самых мощных языков высокого уровня позволяющий делать то, что не позволяет делать для C++ (согласен с этим, но это не всегда хорошо, иметь возможность сделать что-то extra - например вызвать ошибку переполнения).
Я не представляю себе ответа на этот вопрос, если вы говорите с профессионалом процедурного программирования, либо с программистом на VB6 убежденным, что он не работал с объектами и они ему не нужны. А С используется потому, что лень (да и накладно) переписывать на C++ (это не единственная причина, но, согласитесь, что-то от правды в этом есть).