А что у вас хранится в разных таблицах, что искать приходится по всем им?
И вопрос по пункту 3: почему "хитрым запросом" надо искать по различным столбцам отдельно?

А в чём принципиальное отличие новостей и статей?
В принципе, можно было бы и в одной таблице хранить...
Но с такой структурой -- да, придётся искать в разных. Результаты поиска можно объединить UNIONом, скажем, если версия MySQL позволяет.
Касательно же поиска отдельно в заголовке и тексте -- это нужно если только вы действительно хотите искать отдельно в заголовке, и отдельно в тексте. Если же явного такого намерения нету -- то
должно быть достаточно.

У этой проблемы есть несколько аспектов. (даже не считая ваши выпады в соседней ветке на эту тему ,) )
Во-первых, fulltext реализован только для таблиц типа MyISAM, и если вы так заботитесь о целостности данных, это повод минимизировать использование этого типа таблиц, а точнее, объём хранящихся в них данных в БД.
Во-вторых, мой и ваш взгляд на вопрос отличается уровнем абстрагированности.
С моей точки зрения, что статья, что новость, что комментарий, что личное сообщение -- все они обладают такими арибутами как заголовок, автор, время написания, собственно текст. Для всех них пользователь ожидает возможности поиска по содержимому и заголовку. Конечно, при поиске по личным сообщениям необходимо наложить ограничение "видимости" для пользователя, осуществляющего поиск. Однако же, это единообразно структурированная сущность, под которую разумно выделить таблицу.
Третий аспект этой проблемы -- это поведение MySQL в том случае, если на столбец в таблице накладывается условие NOT NULL. Дело в том, что будучи СУБД, работающей как с транзакционными таблицами, так и таблицами, транзакции не поддерживающими, в случае, когда в запросе INSERT/UPDATE/REPLACE для записи не указано содержимое поле с атрибутом NOT NULL, сервер ведёт себя не совсем ожидаемым образом -- он не возвращает ошибку, а записывает в такое поле "умолчальное" значение, например 0 для целочисленного типа, пустую строку для символьного и т.п. Причём в стабильной версии такое поведение характерно для всех таблиц, даже поддерживающих ROLLBACK. В бете 5 ветки изменить такое поведение, кажется, возможно, но бета -- она бета и есть. Таким образом, сохранение целостности данных вроде "обязательного указания автора статьи" этим аттрибутом не добиться, и всё равно это придётся отрабатывать на клиенте, и плодить множество таблиц под новости отдельно, под статьи отдельно смысла нету.