I'd say that the advice is outdated, but I'll try my best to explain and you can decide.
"Bailiwick" is the term used for the namespace a nameserver is considered authoritative for. If example.com is delegated to ns1.example.com then all of the DNS names ending in example.com are in-bailiwick. foo.example.com, bar.example.com, foo.bar.example.com and so on. If example.org is also delegated to ns1.example.com, then names ending in example.org are also considered in-bailiwick for that name-server to return.
When example.com is delegated to ns1.example.com there's an obvious circular dependency; how can ns1.example.com be resolved without first resolving example.com? The way that this is solved is by using glue records. A glue record is when you tell the name-servers for the parent zone (.com in this case) what the IP address for ns1.example.com is. That way the com servers - when asked about www.example.com can say; "actually, you need to ask ns1.example.com, and by the way here's the IP address for ns1.example.com".
With an in-bailiwick delegation and glue record in place, a query can get all the way to the server it needs within 2 or 3 queries.
Now, if example.com is delegated to ns1.otherdomain.net, the delegation is out of bailiwick. Now when the resolver asks the com server for www.example.com it gets a response that says "you need to ask ns1.otherdomain.net". But the resolver doesn't know the IP address for ns1.otherdomain.net. So now it has to put the original query on-pause and go and resolve ns1.otherdomain.net. This is part of why resolvers are called "recursive resolvers" - they have to recursively resolve all dependencies.
Of course ns1.otherdomain.net could itself require out-of-bailiwick recursion, and the process could get quite lengthy. That's why some guides recommend against it - especially when managing you're own DNS; you may as well make everything in-bailiwick.
So how do we manage this? A few ways;
Firstly, there's no reason that managed DNS customers can't use in-bailiwick names anyway. Route 53 customers, for example, are free to create their own names that resolve to their Route 53 name-servers and to use those names. For a real world example, if you "dig amazonaws.com" you'll see that we have four names ; r[1234].amazonaws.com that actually point to regular Route 53 IP addresses.
Secondly, the nameserver names used by large providers are usually well cached. At Route 53 we host a lot of customers domains, and many many domains refer to each name like "ns-22.awsdns-02.com.", so for that reason the names are usually very well-cached, even if your own domain is low-traffic.
Thirdly, we chose TLDs that are large, popular and well-run. .com/.net are operated under a single contract by verisign, so if you do; "dig allcosts.net @g.gtld-servers.net" , you'll see that our .com and .net customers actually get the benefit of two in-bailiwick glue records (we have two nameservers that end in .com or .net). Customers with domains ending in .org or .co.uk get one each.
Fourthly, our nameserver domains are themselves exclusively delegated to in-bailiwick names, for example if you do; "dig awsdns-50.net. @g.gtld-servers.net", you'll see that all four of its nameservers are handled as glue-records. This limits the amount of recursion a resolver must do to just one level deep.
Our goal here is to be able provide a simple easy-to-use set of names that work well and are robust regardless of the customer's own domain of choice, without having to maintain hundreds of nameserver names in every single TLD.