1) Subdomains. If you're app utilises subdomains, you need to use a TLD.

2) Integration with development tools like http://pow.cx/ or https://github.com/puma/puma-dev allow you to automatically startup and shutdown apps. This is useful when you're juggling multiple apps.

3) Security. Using a standard domain/port for local development opens you up to exploits like http://benmmurphy.github.io/blog/2016/07/11/rails-webconsole...

No, that's fine--it's only an issue if you depend upon CORS and cross-domain cookies to test browser-based applications:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_con...

I've found the dev process to be a lot easier if the development environment mirrors the production environment. So I'll spawn jails and/or vms for the database server, for the various bits and pieces of the apps/environment. It means less things that can be forgotten about as an app gets pushed to staging/production, and that documentation becomes easier. Also, names are usually more memorable than numbers, so it helps keep things moving while you're working on things.

I work on a lot of different projects locally, so the username / password auto fill for them needs to be different. Using local host for all wouldn't work.