In most of the cases I've seen so far with multiple regions / POP (4 different companies of different sizes and verticals) the software never being deployed in another reason is the fundamental reason. Reasons ranged from "we hard-coded us-east-1 everywhere and don't know how to test region independence it turns out" to "we have 3 weeks to try to make our software distributed between different regions but have nowhere near the resources to test it well let alone develop anything new for it." Automation is completely remedial and non-repeatable in most of these companies that rarely provision clean environments from scratch. By keeping regions the same between different environments, you reduce the number of possible differences.
Some services in AWS are also not available in others (I'm quite familiar with AWS Data Pipeline not being available outside the "core" regions like us-east-1, eu-west-1) and having services in one region make usage of resources in another region is a huge change when most developers outside ones with technology literate customers are under the gun to push features out fast over sound design. The matrix of services and configurations necessary to mix and match regions and availability zones is non-trivial if you make extensive usage of AWS services above the IAAS layer.
Also, cross-region VPC peering has a TON of limitations that rather annoying depending upon how well your network has been architected (by default in most companies outside enterprises with a deep bench of network engineers, this would be rated at "complete crap barely better than a typical home wifi network"). Heck, even though I'm non-dumb at networks I have to keep reminding myself of various cross-region VPC limitations when working with refactoring cross-region VPCs like where you can reference security groups, how to propagate Route 53 records, etc.
