> Сам Node выполняется в одном процессе(кластер не берем)
Потоке! В одном потоке на процесс, JS так был задуман изначально, поскольку JS в браузере приходилось делить процесс с кучей других вещей, включая конкретно рисовалку отрендеренного dom.
> Вопрос как выполняются все асинхронные штучки платформы, например то же сохранение файлов?
Сохранение файла - это вызов интерфейса операционной системы. Нода при этом физически с файлом не работает и свободна, в этом и фишка. При правильной организации Нода всего лишь жонглирует стримами, перекладывая стримы чтения в стримы записи (не всегда так получается, но в целом суть такая) - это копеечная операция.
> если мы переходим в плоскость запуска отдельных процессов, то не понятно что дает платформа - тоже самое можно сделать гораздо проще и на классических языках Java/C#.
Все так, все преимущества ноды будут сводиться к "просто я знаю ноду". В моем вышеупомянутом скриптике Нода лишь контролирует все сверху, самое критичное делает программа ImageMagick, написанная на C. И не надо бояться процессов, процесс - это основа философии Unix, процессы плохи только в контексте проблемы 10k соединений, в контексте тяжелых задач накладные расходы на создание процесса ничтожны.
> Мне на данный момент критично меньшее использование ресурсов железа, т.к. под разбор могут попадать сотни тысяч файлов одномоментно
Ну совсем одновременно смысла нет, для таких вещей существуют диспетчеры задач (очереди), Сelery например, есть клиент под Ноду:
https://github.com/mher/node-celery (комрады возможно подскажут более Node-style диспетчер). Создаем очередь, забиваем туда задачи, контролируем выполнение, можем отключаться и подключаться снова (между http-запросами например). Главное - загрузить все ядра на 100%, для этого хватит одновременного выполнения всего нескольких задач.
> меньшее использование ресурсов железа
на 99% это будет зависеть от реализации самого парсера, как организовать работу этих парсеров и управление задачами - в контексте железа дело десятое.