Зачем разделять файлы на реализацию и интерфейс в с++?

Интерфейс – кнопка. Реализация – то, что произойдёт при нажатии на кнопку. Разделение кода позволяет менять реализацию, сохраняя интерфейс. Только одно это требует их разделять.

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

Если вы про .cpp и .h, то это не реализация и интерфейс, а реализация и определение.

Лепить все в один файл - это мешает в основном в тех случаях, когда потом приходится в этом файле что-то изменять.
Попробуйте и увидите.
Когда добавляете, скажем, новую функцию, или новый using namespace в файле .h, то IntelliSense в Visual Studio не сразу об этом узнает и не сразу начинает ее отображать в коде, где инклюден этот .h. Даже обычное построение и запуск отладки не помогают. Нужно скомпилировать этот файл со всеми заголовками, и тогда функция станет видна.
Если бы функция была реализована в .cpp, то достаточно запустить обычное построение/отладку - и функция точно стала бы доступна там, где инклюден заголовок с ее определением.

С другой стороны, если требуется написать модуль для быстрой интеграции в проект, и этот модуль в дальнейшем особо не планируется модифицировать, то, очевидно, проще его сделать одним файлом .h, который кинуть рядом в папку и проинклюдить. А был бы .cpp, то его мало кинуть в папку, его бы еще пришлось бы так или иначе добавлять в список компиляции (компилятор должен скомпилировать каждый cpp и в дальнейшем компоновщик должен все файлы obj скомпоновать в exe).

Реализация и интерфейс (точнее, бизнес-логика и интерфейс) - это другое. Под интерфейсом имеется в виду GUI. Под логикой - то, что происходит при взаимодействии с GUI (блокнот сохраняет файл и т. д.). Они должны быть разделены для того, чтобы при изменении интерфейса не приходилось грузить себя бизнес-логикой, как и наоборот, и чтобы это вообще могли разные люди делать.
В вебе имеет смысл пойти дальше и еще отдельно выделить Controller. Там всегда сперва юзер проходит по ссылке, а уже потом в ответ получает View (интерфейс страницы сайта) с Model (бизнес-логика). По разным ссылкам разные связки View-Model. Вот в Controller и задаются соответствия, по какой ссылке что вернуть в ответ. Это паттерн MVC - Model-View-Controller.
На десктопе это избыточно. Окна вызываются непосредственно друг из друга (нажали кнопку - открылось второе окно), а не через общую "точку управления" (через ссылкиы). MVC не нужен, достаточно MV.