In my view, ownership and garbage collection are not opposites of a spectrum, they are separate concepts.
Ownership is about who "owns" some memory, ie who controls access and modifying it.
Imho this should be done during the entire life time of all objects. I also believe this is done in any language, even in languages like Python, Java, and C#. If you don't do this, you are without clue how or when fields may change, which sounds to me like a good road towards long bug hunt sessions.
Memory release is only relevant at the end of the life time of an object. If you have enough memory, you don't even need a memory release policy. You still need to handle ownership though (thus showing memory management and object access are different things).
More practically, if you use explicit destruction (delete x), you get full control when the object releases its resources. Automagic garbage collection typically doesn't give you any guarantees about that. In addition, you get memory leaking as additional problem if you're not carefully dropping unneeded links after you're done with them.
I used the Hans-Boehm collector in a simulator as a replacement of a reference counting mechanism, which proved to be too error prone (in C, ie no destructor call to hook into). It worked great for about 7 years until the software was replaced, although I have no data on how much time was spent on collecting etc. The setup was extreme in other ways too (it did maximal sharing of all data), so numbers would probably not be of much use anyway in other situations.
Despite this success, I am not convinced it is generally useful. You handle ownership anyway during the life time of an object, which means you normally know exactly when you should destroy objects, so why not make that explicit then?
The main useful model that fails in this case is shared distributed read-only access. That is however easily resolved by using techniques like std::shared_ptr and friends to emulate your shared links. I programmed an expression evaluator with shared links for read-only objects, and it does work quite nicely; you never worry about release of the data. The model mostly works due to objects being read-only, so sharing them with anyone is not giving problems.
There is also std::unique_ptr and friends for your exclusive ownership links that move around. So far, I have not found a use for std::unique_ptr, although I am sure there exist valid use cases.