For that example, I heartily agree with you.  Having carried significant value of gold and silver through international airports, I can attest that it is not effortless.

Your example speaks to physical exit rather than monetary system exit.
No argument against brain wallets, I leave argument that to Gavin.
They each have uses.  Both are "Exits".

For example, it may be hard to leave a brain wallet where, if you are incapacitated, someone you want to find it will find it.
Sure, the protocol allows for coins to be spent automatically after a time, and one could program a dead-man switch to push inheritance out.  Its just something you get for free with material commodities.  Its exists outside a head and outside a computer.  For some purposes, that is a feature, for others it is a bug.

The two are almost opposite in function but united in purpose, and so are excellent compliments to each other.

The general parameters of a HashFast GN ASIC are:

• Each ASIC substrate contains 4 separate die.
• Each die contains 96 cores.
• Each core contains two complete double hash engines, which share work across one job
• Hash cores may nominally be clocked at 550 Mhz¹
• Hash cores are rated for clocking at up to 700 Mhz under standard operating conditions
• Clock rates higher than this, and voltage levels lower than the nominal 0.81V, are outside of
  normal operating conditions.
• Cores search for nonces at (host specifiable) hardware based levels of Bitcoin Difficulty up to
  the ridiculously high limit of 7.922x10²⁸

Therefore, each GN “ASIC” looks like four addressable ASIC's in the context of the previous chapters
in this document, providing a total of 96 * 4 * 2 = 768 double hash cores operating nominally at 550
Mhz, leading to a nominal hash rate of 422.4 GH/sec.

Operation at 700 Mhz leads to a total hash rate of 537.6 GH/sec, but sustained operation at this level
may run into power distribution or thermal limitations, depending on cooling efficiency.

Operation beyond this clock rate, even if maintained within power and thermal limits, may lead to
degraded hash performance as hash cores start to make mistakes. If attempting to do this, host software
should monitor nonce rates and/or perform periodic testing of cores in order to set performance limits.

Modules which are over-clocked will contain logs of such operation, which may void warranty.

It is possible, due to yield, that some core(s) on some die may not work properly. A self test mechanism
in the module micro-controller provides a way to advise the host so that these cores can remain unused.
The guaranteed throughput of 400 GH/sec allows for a certain number of faulty cores.

^{1 Preliminary data – subject to change}