These implicit conversions (a) call Thread::current() most of the time unnecessarily and (b) Make it hard to see where Handles are required vs. oops in the source code and (c) are sloppy.
It turns out that there aren't that many any more.

Also, there are cases where we have a Handle and pass to a function expecting a Handle, but first convert to an oop, which then implicitly converts back to a Handle:

Handle h(some_oop);
F declared as F(Handle x);
call:
F(h());    // h() converts back to some_oop, then converts to a Handle.

Why does this matter?  Part of GC root scanning is scanning these Handles which are pointed to by the current thread.  This is done in a safepoint.  The number of Handles varies widely at any point in the execution of the vm.  I found a case where there were 1000s of Handles for the contended_loader_lock for the boot loader, which is essentially Array[0] of Object.

The Handles require that there are HandleMarks judiciously placed in the code to clean up Handles that have gone out of scope.  Placing these HandleMarks are a dark art.   This was a relatively efficient scheme when all Metadata Handles were also included in the HandleMark, because there were so many of them.   Metadata Handles (methodHandle and constantPoolHandle) are now not included in the HandleMark and have appropriate C++ constructors, copy constructors and destructor functions.  KlassHandle and instanceKlassHandle are not in use (null).

That leaves the Handles that are left to use HandleMark.  Since Handles aren't as pervasive as the union of Handles and MetadataHandles, we should change Handle to have constructor, copy constructor, equals and destructor functions and passing by const references, and remove HandleMark because nobody knows when to use them anyway.

This RFE is to simply remove the default constructor so people stop using that inadvertently.   A future RFE would be to change to make Handles properly scoped objects.