Буду на ходу разбирать почему же #helmговно 1. Оно сегодня

при удалении релиза удалило то, что в релиз не входило :) - Юзаю хельм более чем пол года, ни разу такого не было.
2. Любой чарт может перезаписать любой template , в итоге никогда не знаешь что твой собственный template тебе вернет. Оправдание этому в доке какое то детское - не может, в случае чего, выдаст ошибку что такая сущность существует. Единственный момент в том, что он парсит пофайлово, и может, например, задеплоить деплоймент, но на сервисе выдать ошибку, тут ты просто делаешь helm delete --purge.
3. Ну package manager должен уж как то гарантировать корректность - созданный тобой package не может быть проверен на корректность, т.к. например некоторые чарты требуют чтобы им задали переменную через --set при деплое
4. Еще эта идея публиковать тарболы в стиле 90х, брр - Не вижу в этом проблемы
5. Еще из неподтвержденых: похоже что если в чарте есть namespace, и оно не совпадает с namespace релиза, то хелм его конечно поставит, но вот удалить забудет :)) - Что за дичь, нет такого
6. Helm.sh/post-upgrade хук: Если это job то следующий апгрейд релиза провалится, так как оно не сможет его создать - никогда не пытался хукать джобы при помощи helm, это вообще выглядит довольно неправильно
7. Еще этот tiller, нафига? Все равно все пишет в configmap, а атомарность create позволяет делать лок на конекретный редиз, так что тиллер вполне себе мог бы жить в клиенте - мог бы, не вижу проблемы
8. никакой транзакционности и роллбэков. может посчитать что изменений нет,хотя если сравнить оъект в helm get release и в kubectl get XXX -o yaml они будут разными - он не обязан воспринимать изменения, это менеджер чарт пакетов, а не парсер ваших кривых рук, в случае синтаксиса он выдает ошибку.
9. все подвязано на labels и selectors ,от этого ты можешь установить новый релиз, удалить его, а оно с собой утянит что-то что было до этого. просто потому что labels совпали :) - Это суть кубернетеса, а не хельма, да и вообще, у вас что, талоны на namespaces заканчиваются?
10. базовые вещи поломаны: релиз может "усыновить" ресурсы которые уже были, в итоге сам релиз фэйлится и пользователь скажем решает его удалить. оно удаляет и то, что реально не было установлено :) или скажем оно забывает про любые ресурсы, в которых явно прописан namespace. ну или самый ад: upgrade after failure, оно делает совсем не то, что кажется - там внутри идет генерация патча на каждый апгрейд, при этом база для патча - последний релиз, неважно зафэйлин он был или нет. в итоге скажем в релизе изменили A, B при этом B сломало релиз, пользователь делает B' и ожидает получить в кубе и A и B', а получает только B' :) - во-первых нет, сейчас он не станет удалять то, что существовало до него и он зафейлился от того, что такое уже есть. А во-вторых если брать основу микросервисов, то и A и B - сущности отдельные и если вы связываете носки с пуговицами, а потом удивляетесь что у вас всё не так работает - это странно.

8, 9, 10 - твой ответ детсад. Сорри

9 - заканчиваются, вот в текущей конторе неймспейсы выдаются с аппрува vp of engineering. То что просто в стартапе на 3 смузихлеба далеко не так просто бывает в конторе на 10к+ сотрудников. Я не говорю что это правильно но так бывает...

Что то скучно отвечать. Можно я вам победу засчитаю?