Yes, you are the odd one. Or never administered enterprise network with a lot of Windows machines and services. Especially with ISA Server.
Though for some time there is a push to just disable WPAD discovery, because it can be used for redirecting the traffic for nefarious purposes and most people don't use a classic web-proxies anyway.
That's where WPAD conversations get interesting... I imagine that for a whole bunch of folks something like default-path-to-internet is sufficient, or having everything hit the proxy and then hairpin some things back internally.
But when you start getting into really big private environments there are all sorts of edge cases that Proxy Auto-Config (PAC) files really help with. For those who aren't aware, PAC files are a single JavaScript function that implement tests on the requested URL (and a few other things) and return either DIRECT or PROXY for where that request should go. And this all runs on the client.
It's like a super-robust exception list that's centrally hosted and the OS handles caching it, checking for changes, etc. Changes to it can be made centrally and the clients will generally use the new one within a maximum of 20 minutes. Trying to manage a proxy exception list on each client is... hard.
Think situations like having numerous proxy servers all throughout the world, users that move around the world, and you don't want to change the client config to access different proxy servers. Or some sites that needs to go through some proxy servers, some through others (eg: for compliance or technical reasons), some direct even though they have a public-ish URL, or not wanting to bounce high-traffic internal sites off the proxies at all. It's basically client-side app layer selective routing to proxies and it's great.
WPAD is just a way to automatically discover the PAC file. While it can be hijacked on a malicious network to point devices through nefarious proxies, if the company stuff is set up right, there's nothing any of those URLs could grab. Or better, tack on some always-on VPN or whatnot when not on the trusted network and all the better.
IMO the DHCP way of doing it is kinda cool, but DNS is so much simplier and that's why it's widely supported. DNS is just DNS... Anything that can query DNS can implement WPAD logic, which is why it's supported on pretty much every browser platform and macOS and Windows and such.
DHCP requires the dhcpcd to get the setting, somehow pass it to each app that needs it, etc. It requires a lot more integration. Windows does it, but only for things that use the Windows HTTP libraries (WinHTTP). macOS could, but I understand why they don't bother...
Linux... Could... But proxy support on most Linuxes sucks. HTTP_PROXY/HTTPS_PROXY is awful if authenticating proxies are used (plaintext creds in an environment variable?!?), basically no PAC file support at all, no transparent Kerberos auth... Blah.
Need to go now, but here is my another $0.02 on this:
yes, complex enterprise networks really benefited from WPAD (at least for some time)
yes, it is primarily Windows because... well, because it was implemented there
and yes, it's not used in *nix-like because for 99% of time any of them are not in the AD and doesn't support NLTM SSO, so on any Windows machine you get a seamless and silent auth on proxy, while any *nix-like at best nagged you for credentials with an explicit modal. Oh, you restarted your browser? Who are you? Can you provide your credentials?
> if the company stuff is set up right, there's nothing any of those URLs could grab. Or better, tack on some always-on VPN or whatnot when not on the trusted network and all the better.
yes, just like in any other case, a proper planning (preferably done before deployment) is a key for a proper security, by not having an attack surface in the first place.
Kerberos, actually, not NTLM. And it is used in macOS (a *nix-like) and works great, either via WPAD (DNS), directly configured PAC file, or directly configured proxy server.
It's Linux end user devices, specifically Ubuntu, that gives us headaches, mostly because there just isn't a system-wide HTTP library that handles it all which apps can depend on. So yeah, the prompting you describe is exactly the problem.
(Not that macOS doesn't have it's own proxy problems... Configured on a per adapter/service basis only? With no easy way to get new NICs a proxy setting via some sort of system-default template? WTF?)
Though for some time there is a push to just disable WPAD discovery, because it can be used for redirecting the traffic for nefarious purposes and most people don't use a classic web-proxies anyway.