I'm not sure if that's a bad pattern to use, but it's the closest I could get to a guess at the sort of thing that might cause a dependency cycle. Generally, your views are a function of your data, so if the creation of a view affects some state data that's used to determine whether that view should appear, or what form it should take, that's likely how a cycle would appear.
It may be something that affects @ObservedObject in particular because I believe it's publishing 'updated' notifications based on the object as a whole, not for individual properties. So, if your object has two properties, and View A uses/modifies property 1 to present View B which uses/modifies property 2, then both are going to depend on the same object, albeit in a way where SwiftUI can't easily determine if there's an order of precedence there. Where possible, try passing bindings down the stack, so the precedence is clear. It's useful to treat @ObservedObject like @State in this respect: there's a single source of truth where that lives, and everything else binds to it, or to the values within it. I don't recall off the top of my head whether '$myObservedObject' would yield a Binding to your observed object itself (i.e. with implied precedence), but '$myObservedObject.someProperty' definitely creates a binding to the underlying value. If you can use that, you'll likely find things easier to reason about.
Another way to think of it is as owner vs. editor. One thing owns state, the other is a helper purely for editing the state. That's the design of the system controls, for example: none of them own any state directly, they just modify something else. View presentation state and suchlike are ultimately owned by ancillary objects created as view modifiers or (internal) generic wrapper views.
In general, SwiftUI would like you to use value types wherever you can. When the project started, that was the whole ethos: using immutable value types for as much as possible, with mutations being a) locked down and minimized, and b) closely monitored to inform regeneration of immutable view descriptions. Views in particular were *only* value types, and the means of updating them was always to re-create the structure itself. That was a conscious decision to prevent bugs related to mutable view state.
For a good overview, WWDC 2016 session 419 can basically be thought of as "lessons learned while writing SwiftUI." It's two engineers on that team describing the ethos behind what would eventually be named SwiftUI.