Да.

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

Но вопрос ТС в простом делении по типу "как для tempdb", то есть сделать в праймари-файлгруппе несколько файлов. При одинаковом количестве дисков (например, один RAID)
Для tempdb это делают по причине, таящейся в логике взаимодействия ядра с tempdb и с файлами.
А у обычных баз логика другая, там это не поможет.

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

Про разделение на системные и пользовательские объекты что то есть (правда, невнятно, хотелось бы подробнее), а вот про разделение, как для tempdb, там нет.
Там есть некоторые рекомендации про разделению на диски (тоже устаревшие и неправильные), но мы то, повторю, говорим про один диск.

Оба утверждения в этом предложении ложны.
С виртуализацией ничего не изменилось в принципах разделения файлов и их типов по отношения к SQL серверу.
Более того, добавились рекомендации от вендоров виртуализации, лень искать, думаю легко найдете рекомендации того-же вмваре по необходимости разделять данные и их типы на разные SCSI цонтроллеры, диски в таком случает тоже будут разными как понятно.Оба инстинны :-)

При чём тут "разделение данных и их типы на разные...", я же писал, что такое разделение как раз имеет смысл, и я его использовал.

Но ТС спрашивает про, цитирую:

То есть ТС сравнивает 2 варианта:
1) в праймари файлгруппе делаем один файл, кладём на диск (рейд)
2) в праймари файлгруппе делаем 8 файлов, кладём на диск (рейд)

Ок, спасибо, не знал про такое исследование.

Нужно только обратить внимание, что график не от нуля, т.е. разница на уровне дрожания кривых (в секундах 1830 для 8 файлов vs 1870 для одного файла в конфигурации с одним рейдом (для 2х рейдов разница больше, 1760 vs 2000, правда, там в случае с одним файлом используется половина лисков, как я понял?).

Я постоянно слышал, что такое разделение ничего не даёт, ну, попробую тоже потестировать...

PS Согласитесь, вещь всё таки нетривиальная, неоднозначная, как пишет автор:
The answer, as with all things SQL (except concerning auto-shrink) is a big, fat "it depends."
In the best case, the eight-file case on two arrays was just over 6% faster than the single-file case on the single array.
I've heard plenty of anecdotal evidence that adding a few more data files for user databases can lead to performance improvements, but your mileage is definitely going to vary.

Несколько массивов то понятно. Думаю, если вместо одного файла на RAID10*16 дисков сделать 8 файлов на 8 зеркалах, то ускорение может быть заметным.

В статье (точнее, в обсуждении статьи) по ссылке выше Рандел делает предположение, что дело в конкуренции при обращении к метаданным:
авторSo presumably the main advantage of having multiple files in a filegroup is to get a potential increase in throughput due to there being less latching contention on allocation bitmaps (PFS, GAM & SGAM) ?