The only configuration officially supported by Cisco is GRE within IPSec, so that's what all the samples show. In this case, the users' traffic is first encapsulated into a GRE packet and then encrypted by IPSec. This is why the crypto map has to match the GRE traffic between the routers, and why I describe it as "GRE within IPSec".
That being said, it is possible to selectively encrypt just some of the traffic within a GRE tunnel, but this is not officially supported by Cisco. The "trick" is to apply the crypto map only to the tunnel interface, and not to the physical interface at all. You also have to configure your crypto access list to match the actual user traffic and not the GRE traffic, just like you'd do with a non-GRE VPN configuration. I've done this and it works, and I've been told by a Cisco engineer that while it's not supported it's not likely to go away. The situations where you might want this are rare, especially now that encryption hardware in the routers is so common and relatively cheap. However, the case where I wanted to do it involved an older router without encryption hardware at a remote site and the customer wanted to tunnel all Internet-bound traffic back to the main site so they could apply their corporate filters and accounting, but they didn't want to encrypt it because of the CPU load - they only needed company-internal traffic encrypted. So, it's not hard to do and it seems to work, but it's not officially supported and could go away in the future.
Regarding the inbound access-list processing on the outside interface, this depends on what version of IOS you have. Before 12.3(8)T an inbound access-list on the outside interface filtered both the encrypted traffic and the decrypted traffic (Cisco calls this the "clear text" traffic). So, you had to have lines in your ACL that permitted both the IPSec traffic - ISAKMP (UDP/500) and ESP (IP/50), and possibly AH (IP/51) - as well as the decrypted traffic, which is GRE (IP/47) in this case. If you weren't using GRE then you'd generally permit all IP traffic between the remote and local subnet(s) specified in the crypto access-list. In 12.3(8)T this ACL processing was changed so that it no longer applies to the clear text traffic - you only have to permit the IPSec traffic. This makes it easier to get a site-to-site VPN working and helps prevent the possibility of unintended traffic being allowed through the access-list, but it also means that if you want to restrict what traffic is allowed through the VPN tunnel then you have to filter it on a different interface. In the case of GRE you'd already have to to that by putting the ACL on the tunnel interface (this is how you can match arbitrary TCP and/or UDP traffic in your configuration), but for non-GRE VPN's you have to apply the list outbound in your LAN interface(s), which can be less convenient. Even so, I prefer the new functionality over the old, since it's simpler and slightly more secure.
I hope this helps.
