First, /32 is the minimum allocation size, which means you (an ISP) can't get fewer addresses than that (not more as the article claims). The reason you'd want to have a minimum allocation size is because it makes routing tables smaller (better for an organization to have just one entry in the routing table that's huge that they can grow into, than to start small and add lots of small entries to the routing table as they grow).
Second, /48 is what ISPs typically give their subscribers, not what ISPs themselves get.
Edit: to clarify, the /32 minimum is a policy of ARIN and RIPE (not sure about the other RIRs). See for example https://www.arin.net/policy/archive/ipv6_policy.html#43 and http://www.ripe.net/ripe/docs/ripe-552#minimum_allocation. There is no mandatory policy for how ISPs should assign addresses to their subscribers. RFC3177 recommended a /48 in most cases, though that has recently been superseded by RFC6177, which recommends more flexibility rather than a one-size-fits all approach. See http://tools.ietf.org/html/rfc6177.
I find the article somewhat reckless in recommending that you ban entire /64s instead of individual IPv6 addresses. It's true that you need to be aware that a home user will likely be in control of an entire /64 (and possibly more), but if the offending IP address is at a university or a datacenter then a /64 ban could sweep up a lot of innocent bystanders. You really need to consider bans on a case-by-case basis.
In fact, I'll bet the malware-infested utility to automate this into a one-click process already exists.
If you don't do this, you're harming innocent people.
I thought the RIR could be assigned a /32 subnet at most (by the IANA), and that the RIR would hand /48 out to ISPs. The book I read on IPv6 is from before RFC6177, perhaps that's where the confusion came from.
In v4, hosts come first and networks second. In v6, networks come first and hosts come second.
In IPv4, the IP address is central to the architecture, and the subnet is secondary. In v6, the /64 network is the core, and everything is arranged around that.
People have been lulled into this state of apathy about crippled IPv4+NAT connectivity (or don't know any better).
The problem is that the network effect/chilling effect wrt app deployment/development isn't something that a user instantly sees, and the other, more immediate benefits are currently only significant for pretty advanced users (who are already aware of how NAT makes their lives hard).
Well that's not true, if the below linked article is to be believed. The DoD has a /16, which is twice as big (bitwise, it's substantially larger in absolute terms) as the /32 the article says is 'the minimum allocation size'.
aforementioned article: http://gcn.com/articles/2007/02/03/dod-to-allocate-its-ipv6-...
The course is free and you can do it on-line. You will have to do certain tasks, (e.g. set up a ipv6 capable mail server), HE will check and if you were successful you enter the next level. If you make it through to sage level you will get a free T-shirt (which in my case they even sent for free to Germany).
The tasks are not difficult but completing the course will take some time. It is hands on experience and I learned a lot. I'm not affiliated with HE in any way.
Maybe you need a VPN to your company, or university? Unless it's some high security stuff, set up a client on the router and route the traffic through it to selected networks.
Or maybe your ISP doesn't offer IPv6 yet and you'd like to use it? Get a tunnel from SixXS, or HE.
Set up a file server, bridge your network with your parents' network, and let them use it. Keep their backups for example.
Create a completely separate open wifi network if you live in a densely populated area. You can also route its traffic through some other host, if your ISP doesn't look kindly on that sort of thing.
Learning without goals in mind seems a little tedious.