People can, and are doing. Much though I'm a happy perl5 programmer, I often use bleeding edge libraries in my implementations when I'm sure that's the best approach (and if it's code for a client after careful consultation with them). People I know doing rails work often use stuff they know may change under them because it lets them ship faster now and they consider it an acceptable trade-off of risks - and the gems they're using generally don't have a spec document at all.
There are risks involved in every technology choice made for every program. If I didn't actively prefer perl5's semantics and community philosophy in a number of places, I'd be seriously evaluating perl6 for use in code where I could guarantee deployment to be pinned against a particular runtime version, just like I -do- use API-unstable perl5 libraries where I can guarantee deployment against a particular library version and the benefits in terms of delivery time outweigh the risks.
There are risks involved in every technology choice made for every program. If I didn't actively prefer perl5's semantics and community philosophy in a number of places, I'd be seriously evaluating perl6 for use in code where I could guarantee deployment to be pinned against a particular runtime version, just like I -do- use API-unstable perl5 libraries where I can guarantee deployment against a particular library version and the benefits in terms of delivery time outweigh the risks.