There are several good reasons. Legacy concerns about buffer overflows and resource hogging and other such factors.

IOW, if you can get the webserver to segfault... you are in with its or maybe even root access.

Most of the concerns are very much overblown, but they are reasonable especially in large hosting setups, or large numbers of shell accounts and other various accounts for people (virtual mail accounts, virtual DNS hosting etc). If you aren't careful you could easily make you machine tippable with nearly zero effort. These are the main reasons for these kinds of decisions.

Others run from "system service uid is forced to <100" for keeping critical accounts not as exploitable, there used to be many many safeguards built into *NIX to protect <100 uid accounts. Unfortuneately they are still practiced, and get in the way many times. But sometimes they save you from yourself. I consider this and reasons similar to be not so good.

The last and most innane reason I know about, is due to PHP being an "interpreted" language, fears of slipping things like we see on twiki (you know misplaced or extra quotes) can break even the most expertly skilled admin. This is more from a lack of maintenance, than a security issue. If you don't take care to manage your systems, or fail to confgure them after install... this is likely to be the reason Debian probably chooses uid of 33. Using 33 causes the reasons in the previous paragraph to come into play... which also then can be turned into the 2 nd previous paragraph.

They are all inter-related, in some way or anther. But you have to remember the olden days when exploits weren't really treated as a threat, but only an annoyance... which led to these practices. Being far from good reasons now.

SELECT * FROM scog WHERE ethics > 0;

0 rows returned.