GRE is just a tunneling protocol - its main reason for existence is toplogy hiding/bypass.
Some examples include:
Tunneling MPLS across a network that may otherwise not support it - MPLS shims are not IP-based, therefore wrapping them in a GRE tunnel allows two routers to appear adjacent when there could be a number of intermediate IP-only devices.
Configuring EBGP sessions with neighbours that are not directly attached - this is often used by Anti-DDoS services to allow your prefixes to be advertised at their scrubbing stations, and traffic delivered directly to you even in cases where they may be multiple ASs away from your border
GRE over IPSEC is another common use that allows upper-layer routing-protocols to be established across IPSEC-based networks, avoiding the often static configuration and routing limitations posed by traditional (eg: Cisco-based) VPN deployments.
This is also an example of the open-ended security that the RFC mentions. This is not an oversight, merely a way of not excluding future technologies from being used (GREoSSL, GREoQuantumCryptography etc).
From the perspective of intermediary devices, the encapsulated traffic IS "Native" inside a GRE header, the fact that the payload is interpreted as additional headers on the terminating device is IMHO largely irrelevant.
GRE is just a protocol that most routers understand and it is simple enough that encap/decap doesn't burden the router too much.
Think of it another way - if you wanted to tunnel IP inside HTTP (perfectly possible, if somewhat inefficient) you would need to implement an HTTP server on all your routers. GRE is just a simpler, stateless, minimalist way to achieve the same thing.