I really think you're getting hung up on the data type; Int vs. UUID String. Yes an Int takes up less characters in an URL but the benefits pretty much end there is just length. There many more cons to the auto-id than anything gained.
An auto-id Int ss also very predictable and someone could spam your site gathering all sorts of data because they know how to increment the Int in the URL. Much more difficult if it's the UUID in the URL. If you want your user list to get scraped and philfered, it wouldn't take much effort to loop through a million API calls your URL and get all your user info and then your competitor would know your entire user base in your app.
Then as you mentioned, yes you could put something else in the URL such as the user name. This has the disadvantage as well that if the username changes then any links using the old name breaks. This is how Facebook is, Facebook and if the user changes their name, there's an underlying ID behind your account and if you change your name, they can go and propagate that name change throughout their systems but any outside links are broken because it's out of their control. Depending on out important it is to you to maintain any deep linking functionality, you could build a history of previous name changes. Honestly you can bookmark any link in your browser now and the internet could remove that link and your bookmark is toast. Happens all the time, someone blogs and deletes a post. A user makes a tweet and deletes it. Your website should gracefully handle a redirect of a broken link anyways.
Another reason why I'm not a fan of auto-ids is that they're only unique within the system that is generating them. If you have a database that is sharded across the globe, Asia vs. Europe, it's a lot of work to ensure that you're not getting auto-id collisions between the two shards if you ever tried to reconcile the database into a single data source. UUIDS can be generate by any application or any shard of a db and you're very unlikely to get an id collision.
I can understand why Neo4j doesn't have an auto-increment feature. In a SQL DB auto-ids are defined as a per-table basis. There are no tables in a graph. There's just nodes. Any auto-id would have be graph unique regardless of the label(s) that a node has. If you were trying to make an ID in SQL throughout the entire database, you'd still probably end up making a dummy id table that all other tables would have to reference to petition for a new id. And think of this, when each table has their own seed for an auto-id, that id value 123 in table A could also exist in table B as well. A user could write a join and it would succeed because the values match but the results would nonsensical. If you used UUID the join would never succeed because no two tables would ever have the same id inside their table data.
UUID is unique across all tables, all dbs, across all the global from anyone else in the known universe, all you have to do is call a function already available in every language.