Shorter is not always better. Giving a random Ruby developer the final code will just confuse him/her. Giving him/her the original code, without comments, (s)he would understand just fine.
Using these default names and a bunch of flags most people don’t use do nothing but make the result harder to read and hide the program behaviour, just to save a couple of bytes on the hard disk.
It is super useful for people who are working within the the larger ecosystem. Exposing the “random Ruby developer” to these idioms, like the -F switch and the idea of field and record separators, will get them more comfortable with record processing in their shell. Most famously, awk also uses -F to specify the input field separator, and perl’s -F switch accomplishes the same thing.
It’s not a question of whether shorter is better.
The article starts with transparent, portable, but verbose code and ends up with opaque, somewhat (though not completely, as @jdp pointed out) ruby-specific, but compact code. Both versions have their advantages, and showing the gradual progression from one to the other is a good way to teach some valuable command-line techniques.