Основная причина в том, что master не откалиброван для дополнительной нагрузки: он не установлен в системе ввода-вывода с надлежащим планированием емкости, трудно перейти к новому месту ввода-вывода, его план обслуживания принимает резервные копии, а резервные копии журнала Частота, необходимая для очень низкого объема деятельности, ее первоначальный размер и темп роста планируются так, как будто никаких изменений не ожидается. Другая причина этого заключается в том, что во многих сценариях устранения неполадок вы хотите, чтобы копия базы данных проверялась, но вам нужно было бы присоединить новый master к вашему экземпляру. Это основные причины, по которым добавление объектов в master не рекомендуется. Также многие администраторы по понятным причинам предпочитают, чтобы приложение использовало свою собственную базу данных, чтобы ее можно было правильно учесть и в конечном итоге легко удалить.
Подобные проблемы существуют и для msdb, но если пуш настанет, было бы лучше хранить данные приложений в msdb, а не master, поскольку первая - обычная база данных (несмотря на распространенное мнение, что это система, на самом деле нет).