You are right that you gain access to the UID of the process/script you exploited. In the case of the Apache identity with no mandatory access control and no proper separation of developer and apache roles, you can:
- destroy or deface the websites run by your Apache
- change websites' code to leak all the user database at a fixed URL that you can then consult
- add malicious scripts to pages to serve malware to the site's visitors
- host your own websites (e.g., to grow the command and control infrastructure of your existing botnet)
With a basic mandatory access control (e.g., SELinux/AppArmor) policy that does not separate the Apache admin role from the actual process (typically, which allows the domain that runs the actual Apache binary to write to apache_*_t files) and with a read-only access to web code you can probably:
And probably a couple of other things... Here you don't care at all about the OS in itself, you care about the ability ot host content, steal data and alter existing and visited websites. The security you retain post-exploit really depends on how well you compartmentalised your OS in the first place.