HSM or smart card?

Both are hardware security. They are built for opposite things: an HSM concentrates key operations at speed in one hardened box; a smart card distributes independent value and protects it in each unit. The cooling, power and cost differences follow from that, not from engineering laziness.

What each is actually good at

	HSM	JavaCard array
Primary job	Hold keys; perform crypto at high rate	Hold value; enforce a state machine per unit
Failure blast radius	one box = every key it holds	one card = the tokens in its slots
Throughput	thousands of signatures/second	tens of commands/second per card, shared bus
Storage model	Keys, blobs, audit logs on disk	Fixed slots in EEPROM, addressed by index
Power when idle	hundreds of watts, continuously	zero — an unpowered card draws nothing
Cooling	required, and it is a reliability item	none
Unit cost	thousands to tens of thousands	a few dollars per card
Validation	FIPS 140-2/3, Common Criteria	chip-level certifications (EAL4+/5+), not system-level
Write endurance	SSD, effectively unlimited for this use	EEPROM, 100k–500k cycles per slot — finite, and worth designing around

The power arithmetic, which is the point you raised

one JavaCard, active       ~10–50 mW (from the reader's field or contact supply)
one JavaCard, idle                  0 W — it is not powered at all
1,000 cards, one at a time          ~50 mW at any instant, plus the multiplexer
1 HSM, idle                   200–500 W, plus cooling, plus UPS

a 1,000-card enclosure, active        single-digit watts
the same HSM, for a year          ~2–4 MWh, before cooling

That is why an enclosure of cards needs no fans: the design already powers exactly one element at a time. A vault of ten thousand cards is still a single-digit-watt device when it is serving one request, because the other nine thousand nine hundred and ninety-nine are switched off.

But an HSM does something a card cannot

Rate. A card in T=0 does a handful of commands per second; an HSM does thousands of signatures. If the workload is "sign a million messages", cards are the wrong tool.
Concentration with tamper response. An HSM is designed to destroy its keys if opened, and it is audited as a system. A card protects itself, one at a time.
Key custody at low latency. No reader, no mux, no protocol — just a network call.

So the sensible split is both, doing different jobs

HSM            the issuer's signing key, at speed, under audit
               (and this is exactly what a vault signer does today, in software,
                on a machine that should be an HSM before real money is involved)

JavaCards      the value itself: one slot per instrument, tamper-resistant per unit,
               independently keyed, independently auditable, and unpowered when idle

In CoinCard's terms: the HSM (or its software stand-in) produces signatures; the cards hold the instruments those signatures refer to. Moving the tokens into an HSM's SSD would put the value back into a database with a nice lock on it — which is the design this whole system exists to avoid.

What would actually change the answer

If the requirement is…	then
millions of signatures a second	HSM, not cards
value that must survive the issuer's own outage	cards, because they hold the value and need no server
a single audit boundary for every key	HSM for keys; cards remain the value store
offline payment in a village	cards, and only cards
maximum value per unit of rack space	depends: cards are ~$5 per 100 instruments; an HSM's SSD is far cheaper per byte but stores no value

Sandbox deployment, USD, English. Figures are order-of-magnitude and stated as such. Nothing here is a certification claim; a production deployment would need the HSM and the chips validated to whatever standard the issuer's regulator requires.