A common reason is backing up apps and data. And while there exist solutions that work without root, such as the internal backup API, none exists which is truly universal, AND works just as well as some of the "root" ones.
I do not see root dying out, despite the aims of the CM team, until we remove the need for root in stock, off-the-shelf, carrier-issued devices. Once carriers stop installing crap on devices which users cannot "disable" from the Settings app, and ruining phones with their "features", we might be getting somewhere.
For my own uses of root, aside from using Titanium Backup to take versioned, encrypted backups, and then migrate data between devices, I also use root to:
1) Fix boot loops and other issues on devices. Yes, this includes stock devices/ROMs. From an expert point of view, no root means having to do things the "slow" way, like wiping all of /data when I know I could just deleted a few files manually from the shell to fix the issue.
2) Writing to files which are on /system by default. For example, I have custom init.d scripts to modify my ROM after each flash, which are preserved with the zip backuptool.
3) Eradicating Gapps from stock devices. There's no need for them, and I get much better battery without them. But I get no choice on stock devices, so I need root (currently) to eradicate any proprietary google apps or frameworks.
I use root to implement privacy protection features which CM rejected. But fortunately for us all, AOSP obliged and added AppOps, which is essentially what I needed anyway - fully granular permissions control. While it's not quite as good as XPrivacy in terms of sheer amount of protection offered, it's better than nothing.
At the end of the day though, I agree entirely this is the way forwards - a while back I said CM should add a set of new permissions, which require the owner-user's password/PIN for installing or upgrading an app using those permissions. These permissions should at least cover:
- Mount arbitrary filesystems with arbitrary flags
- Backup data of other apps, without itself getting access to said data (ie. requires encrypted app data containers, that the backup app doesn't get access to)
- Restore data of other apps, again without direct access to the plaintext data
- Remounting RW, deleting file from /system, remounting RO
- Remounting RW, adding file to /system, remounting RO
- Direct access to input devices (ie. for stylus gesture handlers etc)
- Configure IPTables firewall with arbitrary rules
- Directly write to arbitrary device partitions (ie. kernel, recovery)
This could be similar to Device Admin, but with the difference that the user must INDIVIDUALLY allow each of these permissions. No "allow by default". No ability to passively acknowledge. They should appear, one-by-one, and require the user to move a toggle to yes, to allow that one, or leave it at no, for the app to not get that ability. And it will still run without it - dev's problem to deal with it via error handling.
Then you have to persuade AOSP to accept these upstream, so it is possible for an expert user to have 100% control of the device they own. And allow all these wonderful things.
At the end of the day, root won't die out until a stock Android device offers this kind of customisation on its stock OEM-ruined ROM. And Google won't allow it, because the carriers won't allow it. If someone told the carriers "tough, it's happening", we might get somewhere. But there will always be a place and need for root for some people, until it's possible to get down and interact with stuff at a low level on Android - I need a proper root shell for accessing dmesg etc, and I want to ensure that only I can get to it... Not just someone randomly accessing adb on my phone.