I think the main problem with using non-tree graphs isn't the choice to use the graph; it's the lack of definition for the edges. Most people, when they first reach for a non-tree graph, choose to weaken the definition of the edge even beyond what is implied by tree edges, which usually means "owns" or "contains" or the like. By default, an edge in a non-tree graph simply means "relates to, somehow". And a beginning user faced with a bunch of nodes are just going to draw a bunch of lines between topics that seem to tangentially relate to other nodes, until they get the big hairball.

If, however, you get stricter about the definition of the edge in a graph, they're superior to trees in many contexts. An edge might mean "predates", or another edge might mean "implies". Those are the two main definitions I use, because when needing a graph I'm usually either thinking of planning (prerequisites, when some things need to be done "before" another), or I'm thinking of arguing/concluding (where some things when combined "imply" a conclusion). It doesn't really work to conflate the two.

You can also combine multiple edge definitions into one graph, and maybe it'd look like a hairball if you're displaying all of them at once, but if you filter it gets more useful.

Two more things... graphs almost always, in my experience, are more visually useful when they are directed, whether acyclic or not. Radial just doesn't seem to have much added benefit. And, a pet peeve is mine is when people use radial UX to display a tree and then call it a "graph". I know, it's a picture of bubbles and arrows, so it's a "graph" in that sense, but most bubble graph software doesn't even support graph data structures. If you grab one bubble and apply gravity, it just shakes out into a tree.