RODCs really are all about physcial security, and not at all about network security. They're an upgrade of ye olde Backup Domain Controllers, that had a nasty tendency to get stolen (and the database along with it).
RODCs come with a unique kbtgt account, so they can't intrude on Active Directory, or decipher kerberos tickets on behalf of WDCs, in case of a physical breach, and by default RODCs don't allow password caching, again in case of a physical breach.
By restricting cached credentials, to only user and computer accounts belonging to a branch office, you limit the fallout in case of a breach, and you allow the branch office to continue functioning in case of a link down.
I know Microsoft technically officially supports putting RODCs in the DMZ, but from experience I can say that this is really more trouble than it's worth. You'll have to audit every single one of your AD integrated applications to ensure that it supports working with a RODC. Why? Because there are still many scenarios that RODCs simply do not support. Certain RPC calls can and will simply fail without reason. These scenarios are described in the Microsoft document Planning and Deploying Read-Only Domain Controllers, subsection Read-Only Active Directory Database, SYSVOL, and Unidirectional Replication:
When a user or application in a site that is serviced by an RODC attempts to perform a write operation, one of the following actions can occur:
- The RODC forwards the write request to a writable domain controller and then replicates the change back from the writable domain controller. For most write operations, the change is replicated back to the RODC during the next scheduled replication interval. In some other cases, the RODC attempts to replicate the change immediately. An RODC forwards a very limited set of writes, including the following:
- Most types of password changes. For more information about password changes, see Password changes on an RODC.
- Service principal name (SPN) updates. When a domain-joined computer has a secure channel to an RODC and Netlogon attempts to update SPNs, the forwarding is done over RPC.
- Some updates to client attributes over Netlogon: client name, DnsHostName, OsVersionInfo, OsName, Supported Encryption Types
- LastLogonTimeStamp. When a domain-joined computer has a secure channel to an RODC and Netlogon attempts to update these attributes, the forwarding is done over LDAP.
- The RODC sends a referral for a writable domain controller to the client. The application from which the write operation originated can then chase the referral and target a writable domain controller to perform the write operation. By default, RODCs send referrals for Lightweight Directory Access Protocol (LDAP) updates and Domain Name System (DNS) record updates.
- The write operation fails: it is neither referred nor forwarded to a writable domain controller. In this case, the application requesting the write should be updated to specifically target a writable domain controller. A number of RPC writes fall under this category.