WP-CLI is at 0.11 and putting it on a server is still a decision rather than an assumption. The argument for making that decision early is that the situations it is best at are exactly the ones where the admin is unreachable: an update that white-screens the site, a password nobody has, a database that needs dumping in the next thirty seconds.
$ curl -O https://raw.github.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
$ php wp-cli.phar --info
$ chmod +x wp-cli.phar && sudo mv wp-cli.phar /usr/local/bin/wp
# the three that pay for the install on their own
$ wp db export backup-$(date +%F).sql
$ wp plugin deactivate --all
$ wp user update admin --user_pass='...'What separates it from editing the database directly is that it boots WordPress properly: hooks fire, so a plugin that filters a user update still gets its say, and an option written through update_option() passes through the same filters it would from the admin screen. Two practical points. It runs as whoever invokes it, so a command run as root leaves files the web server cannot write — a common way to break the media library the following week. And it uses the CLI PHP binary, which on a lot of servers is not the one PHP-FPM runs; a box with 5.3 on the command line and 5.4 behind the web server produces failures that make no sense until wp --info is read carefully.