I installed all the dependencies for neon-settings and sudoers.d/ files worked normally. Installing the specific neon-settings package breaks the functionality.

Can confirm.

I seem unable to reproduce this:

Welcome to KDE neon User Edition 5.15 (GNU/Linux 4.18.0-18-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

The programs included with the KDE neon system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

KDE neon comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

user@oem-pc:~$ sudo ls /snap
[sudo] password for user
user@oem-pc:~$ echo 'user ALL=(ALL) NOPASSWD: /bin/ls' | sudo tee /etc/sudoers.d/foo
[sudo] password for user: 
user ALL=(ALL) NOPASSWD: /bin/ls
user@oem-pc:~$ sudo -k
user@oem-pc:~$ sudo ls /snap
README

Results here are unchanged. Removing neon-settings allows sudoers.d/apt to work but it does not when neon-settings are installed.

The issue appears to be specific to apt and apt-get. Echoing Harald commands do indeed work for 'ls' but '/usr/bin/apt' in sudoers.d does NOT work when neon-settings is installed, but does when neon-settings is not installed. Same goes for '/usr/bin/apt'. '/usr/bin/add-apt-repository' works with or without neon-settings installed so it is not related to the '/usr/bin/' folder but appears to be specific to apt and apt-get. All of the above 'apt' related commands and others are in a single file together on a single line and all but apt and apt-get work without a sudo password.

I confirmed this on a VM as well as on my bare metal install. To recap:

While neon-settings is installed:
/bin/ls in /etc/sudoers.d/foo does allow 'sudo ls' to work without a password.
Others, like 'sudo pwrstat' and 'sudo btrfs' that are on my system also work.
Identically formatted '/etc/sudoers.d/apt' containing '/usr/bin/apt' and '/usr/bin/apt-get' among other commands all work EXCEPT apt and apt-get.
Uninstalling neon-settings allows 'sudo apt' and 'sudo apt-get' to work without a password with no other modifications.

Could someone specifically test this against /usr/bin/apt and/or /usr/bin/apt-get to confirm? Test procedure requested please: 

With neon-settings installed, use Harald's series of commands above and substitute '/usr/bin/apt' for '/bin/ls'. Then enter 'sudo -k' and 'sudo apt update'. Assuming the result is a password is requested, do CTRL+C to cancel and then uninstall neon-settings and re-test. Be sure to do 'sudo -k' between commands if package uninstall is done in the same terminal to force a reset of the environment. Please report results here. Thanks.

You have to use /usr/sbin/apt on neon nowadays.

Just confirmed Harald's Comment 5. I edited my /etc/sudoers.d/paul file and changed /sr/bin/apt and /usr/bin/apt-get to /usr/sbin/apt and /usr/sbin/apt-get and now both apt and apt-get don't prompt for my password.

Seems like an odd way to implement a change like that; /usr/sbin/apt calls /usr/sbin/apt-overly which calls /usr/bin/apt. No wonder sudoers got confused!

At least this explains why my sudo apt overrides worked in the 16.04 version.

Thanks for running it down, I would have never found this.

So neon-settings redirected bin/apt to sbin/apt ?

It's a bit of a flimsy override but its in fact the most reliable way to do it we decided.

sbin actually just *happens* to be before bin in $PATH. so, if you just run `apt` on a terminal that will be /usr/sbin/apt (the override). If you were to run it with absolute path `/usr/bin/apt` you'd not get overridden at all. That is in fact part of the reason why it is in sbin. Scripts, which generally should call by absolute path (because the user may have overlay'd apt in a very similar manner to what we do + security reasons), are not affected by this.

All that said, you might actually want to look into replacing your use of apt with pkcon, the cli frontend for packagekit, and then regulate password-less use via polkit. The polkit profiles should give you much finer control over what a user/group may do without password auth.
Allowing NOPASSWD on all of apt is a fairly substantial security threat. e.g. apt can install local debs, so should the user(s) affected by NOPASSWD get compromised there is a readily available way to escalate to root-level access through apt.

Thank for the detailed info. Always good to be armed with the facts in my world. 
Funny you should make that recommendation about pkcon as I starting looking into it right after my last post here. My apt use was due to the burgeoning problems with early Discover in conjunction with Muon being without a dev. I just put apt into some aliases and made the suoders entry and went full CLI for updates and installations. That was about 5 years ago I think? pkcon looks good in the CLI and I'm looking at the GUIs also. 

Thanks again. Beverages on me if we ever meet in the real world :)

BTW, agreed on the security issue. I had narrowed it to just the specific PC and it's in a rather controlled environment. I had widened it (ALL ALL etc.) when trying to trouble shoot this issue. My laptop does not have this setup.

I haven't ventured into polkit much, but worth a look. Thanks again.