F5 Internal vs External - Different Instances

What would be the typical reason for doing the route domains to separate external and internal if we were controlling the traffic flow between the zones already with something like AFM for anything that may be using the F5 as a default gateway?

If you are using AFM there isn't much benifit. The main reason for route domains is to maintain separate routes for network, which typically is used to default route to different firewalls/firewall interfaces. With AFM, you don't require that.

There are pros and cons on both approaches: I would add manageability and maintainability to the play, depending on the complexity of the configurations - and possibly add partitioning. Note that this brings in complexity if one needs to address config objects across partition boundaries. Partitioning keeps config objects within its boundaries, also makes transfer of those to separate devices easier. Also I would use iApps if possible as they contain relevant objects to their own folders - makes dependancies more straightforward, though adds complexity to the resulting config-files. But still on manageability point of view I'd use them. F5 supported iApps are possible less error prone than config by hand and should address more use scenarios. Separate vCMP - if done properly can be very secure, with external FW or AFM. On the other hand if you have separate vCMP instances, there will be additional complexity on the HA clustering and upgrades, but makes for example sw upgrades more contained, you may need to do sw upgrades quite frequently on the external (Internet) facing side (just run an iHealth check every now and then to see if there are new vulnerabilities..). On single vCMP the sw upgrade is global. Same applies to config or other errors, which eventually will happen if the config changes - try to keep "error domain" small to make effect smaller and troubleshooting simpler. Pretty often a customer has security guidelines cemented which deny using same device on multiple security zones - except if it is a firewall (AFM is). I would try to find a balance between manageability, maintainability and simplicity - and security. Anyway typically plan for long term use and that the config can grow/change substantially over the time.

What would be the typical reason for doing the route domains to separate external and internal if we were controlling the traffic flow between the zones already with something like AFM for anything that may be using the F5 as a default gateway?

If you are using AFM there isn't much benifit. The main reason for route domains is to maintain separate routes for network, which typically is used to default route to different firewalls/firewall interfaces. With AFM, you don't require that.

There are pros and cons on both approaches: I would add manageability and maintainability to the play, depending on the complexity of the configurations - and possibly add partitioning. Note that this brings in complexity if one needs to address config objects across partition boundaries. Partitioning keeps config objects within its boundaries, also makes transfer of those to separate devices easier. Also I would use iApps if possible as they contain relevant objects to their own folders - makes dependancies more straightforward, though adds complexity to the resulting config-files. But still on manageability point of view I'd use them. F5 supported iApps are possible less error prone than config by hand and should address more use scenarios. Separate vCMP - if done properly can be very secure, with external FW or AFM. On the other hand if you have separate vCMP instances, there will be additional complexity on the HA clustering and upgrades, but makes for example sw upgrades more contained, you may need to do sw upgrades quite frequently on the external (Internet) facing side (just run an iHealth check every now and then to see if there are new vulnerabilities..). On single vCMP the sw upgrade is global. Same applies to config or other errors, which eventually will happen if the config changes - try to keep "error domain" small to make effect smaller and troubleshooting simpler. Pretty often a customer has security guidelines cemented which deny using same device on multiple security zones - except if it is a firewall (AFM is). I would try to find a balance between manageability, maintainability and simplicity - and security. Anyway typically plan for long term use and that the config can grow/change substantially over the time.