It is probably a bad idea

Your dereference() will even work if you don't give it a pointer-like type:

int foo = 42;
std::cout << eld::traits::dereference(foo) << '\n';

That prints out 42. Maybe it's still simple when we deal with (a pointer to) an int, but what if we have a pointer to a pointer? Do you want the first pointer or the second pointer? Or dereference all the way until we get a non-pointer value? It's not even that far-fetched: what if we have a function that that operates on an iterator, and the iterator may or may not be passed via a pointer, but the iterator itself could be just a plain pointer (like std::begin() on a C-style array)?

It would really be much better if you put the burden of dereferencing on the caller, as the caller knows best what to do.

Perhaps as a compromise, assuming we want a T but it might be passed as T&, T* or std::smart_ptr<T>, you could change dereference() so that you have to provide the expected value type T as a template parameter.

About supporting std::shared_ptr

This code does not support the concept of shared pointer though. dereference does not increment a counter, so using an obtained reference is dangerous.

If you want to do call derefence() on a std::shared_ptr, I would not worry about it. Your derefence() returns a reference, so it's already required that you should keep the original object alive for the duration you are using the reference you got. This is no different from dereferencing or calling get() on a std::shared_ptr itself.

It does not work on raw pointers

Surprisingly, while your code works fine with smart pointers, it doesn't work with raw pointers. The problem is that the first is_pointer_like version doesn't actually remove the pointer from T. That's easy to fix:

template<typename T>
struct is_pointer_like : std::is_pointer<T>
{
    using value_type = std::remove_pointer_t<T>;
};

It doesn't work with temporary std::unique_ptr and std::shared_ptrs

The following doesn't work either:

std::cout << eld::traits::dereference(std::make_unique<int>(42)) << '\n';

Even though it works if you pass in a named std::unique_ptr variable. The reason is that while you correctly handle const in the function dereference(), you are missing specializations of is_pointer_type that handle const std::unique_ptr and const std::shared_ptr. You have to add:

template<typename T, typename DeleterT>
struct is_pointer_like<const std::unique_ptr<T, DeleterT>> : std::true_type
{
    using value_type = const T;
};

template<typename T>
struct is_pointer_like<const std::shared_ptr<T>> : std::true_type
{
    using value_type = const T;
};

Adding a test suite would be helpful in finding these kinds of problems.

Simplifying the code

One issue at the moment is that you have to explicitly handle both std::shared_ptr and std::unique_ptr, and const and non-const versions of both, duplicating a lot of code. With SFINAE or C++20 concepts, it might be possible to make an is_pointer_like that handles both smart pointers in the same way, and might even support other smart point types that have the same interface. In particular, both std::shared_ptr and std::unique_ptr have a member type element_type, and a member function get(). It would then also work with the deprecated std::auto_ptr. Ideally it looks like:

template<typename T>
requires is_smart_pointer_like<T>
struct is_pointer_like<T> : std::true_type
{
    // Deduce the value type such that const is propagated
    using value_type = std::remove_reference_t<decltype(*std::declval<T&>())>;
};

Then the trick is just to implement the concept is_smart_pointer_like. But note that there is nothing in the body that uses element_type or get(), it only needs T to be dereferencable. So perhaps you could even just check for that, as it will then also work for regular pointers, but on the other hand this might match more types than you like. For example, it would then match iterators.