There is a couple of reasons for this:
SharePoint is from companies point of view a Microsoft product, so if there is a security risk then it's seen as Microsofts fault. This is the reason for Microsoft to putting in a lot of security into SharePoint which by default isn't in ASP.Net like:
- not running full trust
- not allowing updates on GETs and unverified POSTs
- only allowing code to access/update more than the current user is allowed to if the developer explicit tells that this should be allowed want to
Traditionelly SharePoint developers developed only part of the page (Web Part) where an ASP.Net developer developer developed the full page. If you don't develop the full page, then it's hard to give this kind of security without a lot of duplicate code if the platform doesn't support it. In ASP.Net then it's up to the individual developer.
This makes it harder to develop for SharePoint, but it makes it easier to develop safe code.
Update to answer update in question:
Examples of Unsafe Updates:
- Any update in a GET HTTP-request as this could be an attempt to cross-site attack example: Attacker has image tag with src set to url to perform update using visitors cached credentials.
- Any update in a POST/PUT/DELETE/MERGE HTTP-request without a valid FormDigest as this could be a replay attack.
- Any update in a HTTP-request done to another site or as another user as Microsoft thinks the developer should really think before doing this.
Examples of safe Updates:
- Any update not due to a HTTP-request. As this isn't from that unsafe Internet.
- An update due to a POST/PUT/DELETE/MERGE HTTP-request with a recent FormDigest from that site and user. As this is the normal way of updating things on the Intranet/Internet.
- Login
- Request Page
- Change something
- POST/PUT/DELETE/MERGE.