The generic statement that BGP is required when you need to route between two autonomous systems is fairly misleading. There are a lot of scenarios in which you may choose to use BGP, or it might even be required.
In the service provider world, BGP is used heavily, as it is THE routing protocol of the Internet - but it sounds like your question is regarding the enterprise. In that case, you may be required to use BGP when interfacing with service providers for Internet and sometimes WAN connectivity, or you may choose to run BGP internally due to it being the most flexible routing protocol as far as routing policy goes.
Some examples of its use in the enterprise:
- Your enterprise controls a block of portable public IP space. "Portable" in this case means that the space is registered to your organization by a Regional Internet Registry, like ARIN. Your organization hosts internet accessible services that utilize addressing from this address space. You typically have two options for letting the world know how to get to you:
a. Your service provider could advertise this space to the Internet via BGP and static route back to your environment.
b. You could peer with your service provider and advertise the space to them via BGP. In the case where you have more than one ISP, this is the only option. You'd advertise the space to both service providers and then use various policy / manipulation of attributes to control the paths incoming traffic takes.
In this scenario, the service providers may each advertise a default route to you (rather than the full internet routing table) and you may want to load balance your outbound Internet traffic across ISP's. In this case, you might need to manipulate BGP to ensure traffic takes the path you want it to and return traffic is influenced back through the same ISP it left on. This is super high level, but hopefully you get the picture.
- Most of the time when you have MPLS links for WAN connectivity, you're not actually doing anything with MPLS. MPLS will terminate on the service provider's Provider Edge (PE) router and they will connect to your Customer Edge (CE) router with a regular ethernet link on a /30 point to point connection. In this case, you'll typically have to redistribute your IGP (internal gateway protocol - OSPF, EIGRP, etc.) routes into BGP to share with the service provider. They will pass those routes through their MPLS network to their PE at your remote site, which will BGP peer with your CE at that site, at which point, you will learn the routes there and redistribute them again back into the IGP at your remote site. The same thing will happen in the other direction.
BGP isn't a requirement here, but it's typically what the service provider will want to run to keep things consistent across all of their connections to customers.
- As said above, you may run BGP inside of your network, which is known as IBGP. It's actually the same exact protocol, but when you run BGP between routers in the same AS, a couple of the behaviors of BGP will change. Anyway, this is really all about control. You may have layer 2 virtual networks for WAN connectivity or even VPN links that you could run OSPF over, but in some designs, you may need more control over routing policy to achieve the behavior you want over these paths, in which case, BGP might be the right tool for the job.
Sorry to be somewhat broad, but every case is really different. When you're just learning networking, especially from Cisco, they will simplify everything to help you understand the concepts. In a way, I think they go too far in insinuating that certain generic statements are "rules" and even test you on them as if they are 100% strict rules.
The best advice I can give is to learn it their way to get down the concepts and pass your certs, but keep your mind wide open. If you want to add something a bit less formal and a bit more real world to your network learning/training, definitely pick up some O'Reilly books (related to the topics you're studying) with the animals on them. You can get them pretty cheap used on the Internet.