On saturday I made some tests and found the root CAUSE of the issue, and the SOLUTION.

The reason "aplay" is called, is because it is used to enumerate sound cards, 
(with the -l argument as in "aplay -l"), by ubuntu-drivers, to find ye-old software modems.
The "ubuntu-drivers-common" package scripts are called by the "kubuntu-driver-manager"
package scripts on login to KDE's desktop. Aplay is also called when going to AdditionalDrivers
or running "ubuntu-drivers list".

The reason why the "pulseaudio" process created by 'aplay' remains running, is because "aplay" and thus
"pulseaudio" receive an empty environment (no environment variables).
    Since "pulseaudio" receives an empty environment, it cannot know from which session or
DISPLAY it was called, and whether another pulseaudio is already running for that session.

Because of that, we end up with two different pulseaudio processes, and thus one interferes with the
other, producing "device busy" errors while plugging our USB headsets/mics/webcams, 
resulting in them not getting fully recognized.

The solution is as follows: Edit this file:

          /usr/share/ubuntu-drivers-common/detect/sl-modem.py

and replace this line:

        aplay = subprocess.Popen(['aplay', '-l'], env={},

with this line:

        aplay = subprocess.Popen(['aplay', '-l'],
      
By removing the named 'env={}' argument, the "aplay -l" receives the environment
and can distinguish the correct pulseaudio process.


Another way to workaround this, but quick and dirty, is to simply add a line:

         return None

right above the aplay line, with the same spacing (indentation level), to disable looking for software modems at login if you don't plan on using dial-up modems :-)


Details:
--------

I obtained the process list by adding redirecting 'aplay' temporarily to a script, which had a "sleep 30" delay, so
that I could get it in "ps axf". 
The process list at the time of calling aplay is:

        \_ init --user
            [...]          
            \_ dbus-daemon --fork --session --address=unix:abstract=/tmp/dbus-l0CdfJrRGy
            |   \_ [dbus-daemon] <defunct>
            [...]
            \_ python3 /usr/lib/kde4/libexec/DriverManager_DBus
                \_ /usr/bin/aplay -l
                    \_ /usr/bin/pulseaudio --start --log-target=syslog

Looking by the process number, for the second pulseaudio instance,
          cat /proc/NNNN/environ
is empty.
I found by tracing the python calls that the file which runs aplay is:

          /usr/share/ubuntu-drivers-common/detect/sl-modem.py

(if I skip/comment the call to aplay on that file, the issue dissapears).
The file "sl-modem.py" belongs to the package:

          ubuntu-drivers-common

and the DriverManager_DBus script which runs at logon belongs to the package:

          kubuntu-driver-manager

which explains why this issue only affects us Kubuntu users, but in reality,
it also affects all Ubuntu users, because any time they enter the
driver manager (either by softwarke-properties-gtk or "Additional Drivers", or
by running "ubuntu-drivers list" in the console) they are going to get a
duplicate process for "pulseaudio" until they restart.


Many Thanks to all the guys in this thread: you pointed me in the right direction.
My Zoom H2n is now correctly recognized with the solution I explained at the top of this post.

Maintainers: 
Please evaluate if removing 'env={}' from the aplay line at the "sl-modem.py" file 
of the ubuntu-drivers-common package is a worthy and safe patch so that 
everyone benefits.

Cheers,
Juan Manuel Cabo