Het probleem van scripts is dat je zelf alle logica en foutafvanging moet bedenken. Met name het opnieuw draaien van een script wil nog wel eens de boel om zeep helpen wanneer je dit niet hebt dichtgespijkerd. Dat is wat het zo complex en tijdrovend maakt. Met die andere tools heb je dat niet, dat is meestal niveau yaml file. Je hebt er echter wel de nodige kennis van het onderliggende OS en applicatie nodig, je moet immers weten hoe je iets installeert en configureert. Het knutselen met dingen als Ansible en Saltstack is ook erg leuk werk, daar zit wel het nodige aan uitdaging in. Je kunt er zelfs modules voor schrijven (vereist Python kennis) en dat met de rest van de wereld delen als je dat leuk vindt. Als je dit soort geknoei echt leuk vindt zou ik zeker eens naar dingen als Ansible, Saltstack gaan kijken.
Allicht heb ik een totaal verkeerd beeld van 'slimme image tooling' maar dat is simpelweg niet mijn interessegebied.
Ansible, Saltstack zijn geen imaging tools. Het is configuration management, provisioning en deployment tooling. Je gebruikt het om je OS te configureren, applicaties te installeren en te configureren, etc.
Voor een bedrijfsomgeving wil je idd een image spoolen maar als Tweaker/hobbyist speel ik liever een beetje.
Dat is het grootste misverstand op dit vlak. Je hebt het liever niet voor je clients omdat je bij wijziging van iets als een driver meteen de hele image moet updaten. Dat soort images zijn vaak ook heel erg groot waardoor je weinig voordeel hebt aan een image. Je hebt meer beheer en de installatie gaat wegens grootte niet bepaald sneller dan een clean install.
Voor servers op een cloud platform is het een ander verhaal maar die images zijn ook aanzienlijk kleiner. Reden om daar images te gebruiken is het feit dat je die makkelijk kunt klonen en aan een nieuwe server kunt hangen. Om die dingen te maken wordt tooling als Packer (maken van de image) icm Ansible (installatie en configuratie van applicaties, bijv. een database server) gebruikt. Erg leuk spul om mee te spelen, je kunt het op je Mac gebruiken icm VMware Fusion.
Er wordt vaak ook een hybride vorm gebruikt waarbij je de basis (een hele kale installatie van het OS) als image hebt en die verder uitbreidt door Ansible/Saltstack playbooks er overheen te gooien. Hoef je maar 1 image te onderhouden ipv tig verschillende

De hoeveelheid data is 1, maar ook bij enkele GB's moet je m.i. je OS en je data scheiden. Zodra die zaken te veel door elkaar gaan lopen krijg je ellende.
Strikt genomen krijg je die ellende ook wanneer je je OS niet ook uit elkaar trekt (stukke applicatie die de logs vol loopt te spammen met als gevolg dat je out of diskspace bent...niet erg op /var/log, wel op / omdat je dan vrijwel niets meer kunt). Dat kan echter niet met macOS en Windows. Daar data en OS scheiden is vooral handig wanneer je met images e.d. werkt omdat je die dan klakkeloos over je OS installatie kunt knallen. Betekent echter wel dat je de ~/Library ook bij het OS moet tellen aangezien daar de nodige applicatie config in staat. Als dat elders staat kun je gezeik krijgen.
Mijn data ga ik echt niet uitzoeken, zodra ik beslis dat iets naar het DAS of NAS gaat dan staat dat daar met een reden.
Ik doelde op dat laatste: door je data gaan en beslissen of je het wil houden, weggooien, archiveren of naar bijv. je externe schijf of NAS wil verplaatsen. Doen veel mensen toch al aangezien schijfuitbreiding van de gemiddelde laptop nogal prijzig is.