I’m not assuming a Cisco implementation at all. RFC 3509 provides some modifications for corner cases (and I’ve used scenarios similar to the last example in that RFC when I want to give an interviewee a really ugly problem to explain), but in almost all cases connecting two non-backbone areas  somewhere other than at area 0 is a bad idea. The person doing it might know exactly what they’re doing, and might have considered the contingencies well. But eventually some regular schlub like me is going to have to troubleshoot it or modify it, and then you get problems.

Whether from differing interpretations or differing customer demands, you can get ABRs behaving differently from different vendors – IOS and JUNOS, for example – and thus the capability to do some curious things with OSPF topologies. And playing around with oddball multi-area OSPF topologies in the lab is a great way to get a deeper understanding of the protocol, so I encourage that. But in production networks I stand by the assertion that correct multi-area design is the traditional “daisy” (area 0 in the middle, all other areas the petals connected around area 0, and no petals touching each other anywhere else).

Here’s a scenario that demands some semantic hand-waving, though:

Take a single ABR that connects areas 1, 2, and 3. That ABR does not actually need to be connected to area 0 for the three areas to communicate (depending, as you cite, on the specific vendor implementation). So traffic is passing inter-area without passing through an area 0.

In this scenario the letter of the law is broken but not the spirit: The ABR itself serves as the backbone, and the OSPF topology is still loop-free, which is the point. You just have the ABR as the middle of the daisy rather than area 0.