I would have thought it would be quicker to test than to ask.
What sort of error are you concerned about?
There is no requirement to impose DLL reference counting by the legacy registry method, but be aware that windows installer reference counts components with the same GUID anyway, using its own internal process.

Why do you consider that  DLL reference counting is a legacy registry method?

Is there a better way than using the Registry Reference Count method?

There is no error in terms of running the Installer or the application because we have knowledge that we have only one EXE that depends on that particular DLL.

The potential problem is that you have more than one EXE, which rely on that particular DLL.

It will be a problem if we removed the EXE while another EXE relies on the DLL (This is done in the installation custom action).

The reason that the registry shared DLL reference counting method is considered a legacy method, is that this method was developed back in the early days of windows operating systems (Win 95 if not earlier ) to avoid DLL hell because of apps uninstalling DLLs and breaking other apps. This was several years before Microsoft released windows installer technology and with it the concept of merge modules.
With Windows Installer technology, each component has a unique GUID but components that are identical in every respect should have an identical GUID. Each component installed by an MSI has the component GUID stored in the registry in a "mangled" form. If another application installs an identical component and the component GUID already exists in the registry, then the component is not reinstalled - all that happens is that the component count for that GUID is incremented.
Of course, now that there are effectively two different reference counting mechanisms available, there remains a risk that a particular file could be installed by non MSI technology and reference counted by the legacy method, whereas another application installed by MSI technology uses the component reference counting method to track installed instances. So now you have two apps which share a file, and each install has a reference count of one, stored in different ways. The uninstallation of either will nuke the file, but at least if it is the MSI install that remains, it can self heal the next time the application is fired up, as long as the source media is available.
This is where you have to decide whether to support both methods of reference counting in your install, or whether to put the DLL into the application folder, register it in that location (if required) and not bother with any reference counting if no other application uses it.
It's a big topic if you throw in methodologies such as DLL isolation by either the .local method or the manifest method, but at the end of the day, it all depends on what you are trying to achieve and who your target audience are - whether this is an internal corporate application or something you plan to sell to Joe Public.