Yes, they do. In many places.
You're creating a support burden by breaking users networking configs with what ever you think should be the way. That's the entire reason for DietPi right? Raspbian doesn't know what they are doing, but you do!
No option for it on my arcade Pi:
pi@arcade:~ $ sudo grep '' /sys/module/$(readlink /sys/class/net/wlan0/device/driver/module | xargs -n 1 basename)/parameters/*
/sys/module/brcmfmac/parameters/alternative_fw_path:
/sys/module/brcmfmac/parameters/debug:0
/sys/module/brcmfmac/parameters/roamoff:1
That link you posted is for a Realtek USB WiFi dongle.
I posted 3 links, they are not all from the USB dongle.
What OS are you using and what board? On device WiFi or a dongle you added later to a board that doesn't come with WiFi?
Moved to community support. You guys can fix what you broke.
Xbian with Buster repositories and Raspi3 on-board wifi.
Kernel is modified though I believe.
Great, this topic is about Raspbian since they are running Raspbian. Again, exactly my point, you guys are trying to force your ways on to Raspbian and that WILL break things.
Edit: Look, we've been doing this with Raspbian / Raspberry OS for over 5 years now. Trust me when I say that you're causing us more head and heartache when you post stuff like this. People will see the directions and copy/paste with absolutely no clue what or why and then it takes us even longer to find out what they did and try to unwind it all.
Well the three links you posted ar all not for the on-board one.
Jesus, it's the concept with multiple sources to show that it works. Are we down to pedantics now?
Praying wont help 
I searched few times to have it switched off via the module for Raspi's.
One size fits all 
sudo tee /etc/cron.d/keep-wifi-alive <<< $'* * * * * root ping $(hostname -I)'
sudo service cron reload
EDIT: forgot the user
Links? I remember many cases in RPi forum where users with no dhcpcd are treated just the same, or even instructed to setup network via ifupdown or systemd-networkd. There are even sticky network threads in the forum that do not mention dhcpcd with a work but setup a static IP via ifupdown only. As said, it's enabled and functional OOTB, the /etc/network/interfaces entry alone makes it become active. So if any official RPi dev or moderator or such did ever made such a statement, then it's either long ago, or, yeah there are always single guys which do not represent the opinion of the whole team/company.
Where do you get all this from? I don't know why Raspberry Pi devs chose to go the way they do, of course there is a reason, we do it the way Debian does, that's all. If you use DHCP, then using a DHCP client is necessary, so shipping one is great, but as with Pi-hole you usually want a static IP, the reason to use a DHCP client is simply obsolete.
Do we want to run a discussion whenever I am posting something now? Do you have an alternative to contribute to help with users connection losses or do you just want to argue against each of my support attempts?
What I posted is an idea, a suggestion, a try to fix things. And the "WILL" in your sentence really makes it impossible to take you serious here, sorry 
.
Google?
Neither do I but that's what they have decided so that is what needs to be configured. Not ignoring what they did because you don't like it.
Yeah, use the module and don't screw with the configurations that aren't used in Raspbian.
It's okay, I never take anything you do as serious either.
Yeah, did you see the stock interfaces that I posted that specifically says "For use with dhcpcd"?
Bad and dirty hack.
Why do you all insist on making it harder on use to provide support when you come up with half assed hacks that screw things up? Please, stop doing that!
How then via the module ?
For Raspbian? I provided links already.
For your custom kernel? I don't know, ask the person that modified the kernel.
It is beyond frustrating to have our limited ability to provide support being actively undermined by people that have no responsibility or need to provide support for what they are posting. It drives me up the wall that people want to cause us problems and want to make it more difficult for us to help people.
Please, truly, stop.
First and second link is for Edimax dongles.
Third is for Realtek.
None are for the on-board.
I'll quit if you want to.
So, you're playing games then. Or purposefully being obstinate and pedantic.
Edit: If you really want to do it and don't want to use modules, then just add to the rc.local.
Since the
iwcommand is not persistant, I added/sbin/iw wlan0 set power_save offto/etc/rc.localright beforeexit 0to have it set at startup (no need forsudosince rc.local already is run with admin rights).
That was what I used to verify what I wrote + I had a quick look into the first network-related topics on the Raspberry Pi forum. I couldn't find something that supports your claim.
We are on Linux here, not Windows or macOS where one hardcoded way exists. Raspbian is a full Linux distribution that ships the whole Debian repository you can choose a large number of different network tools from. So there is no need for any specific setup, at best specific features, scripts or tools expect specific setups. I know the RPi tools very good, studied and reviewed their code and can say that only a single feature depends on dhcpcd, which I mentioned above. Those tools are an offer, not something that a Raspberry Pi or Raspbian user is forced to use. Something basically implied for any Linux distribution, as long as you don't have a support contract that clearly defines what is implied and what not. You have a point for inexperienced users, where sticking with most used defaults is first of all safer, but I do not suggest here to do a crazy offroad setup but a very small change to switch to a very well proven method that is the default on Debian and pre-installed natively on Raspberry Pi OS as well. You are the one who wants to enforce a certain setup and dislikes any customisation, even that a default may not be the best solution in every case, not me and not the Raspberry Pi devs.
Ah sorry, I missed your post above. Should be tried, but indeed those are from pre-dtoverlay and pre-onboard RPi times, so it will very likely not work with Zero W onboard chip. If it works, indeed it's the cleanest solution, so worth to give it a try 
.
Btw, different RPi models do use different onboard WiFi chips, e.g. RPi4 is Cypress CYW43455 and Zero W as mentioned is a Realtek one, RTL8188CUsomething.
That is the default empty interfaces that loads the interfaces.d subdir configs only, exactly the same as on Debian. That it says that it's currently to be used with dhcpcd (it's empty!) does not mean that you're not allowed to touch it or that a self-destruction mode is enabled once you disable dhcpcd. dhcpcd is Raspberry Pi OS's default suggestion for a very common network setup with a single interface and DHCP. Aside of it, Raspbian is Debian, the beta Raspberry Pi OS 64-bit uses in fact the regular Debian repositories, so of course all that works on Debian works on Raspbian just as good.
It's not about what anyone wants, but about what works. If there are any module or dtoverlay options, then this would be the easiest and cleanest, I agree. The rc.local suggestion works in most cases, but rc.local is deprecated, not always enabled and it loads very late at boot, especially when there is a service timeout included (probably one that is not recognised). Also as said, iw might not work on RPi Zero W, it did not for schliden, so I suggest a udev rule with iwconfig:
echo 'SUBSYSTEM=="net", KERNEL=="wlan*", ACTION=="add", RUN+="/sbin/iwconfig %k power off"' > /etc/udev/rules.d/10-disable-wifi-powersaving.rules
But if power savings is not actually the issue, ruling out dhcpcd is a viable next step.
Not only that. My impression is that you forcefully try to find arguments against everything that I am saying (but probably that is my personal impression). If you are not able to at least try to give things an objective chance, despite personal dislikes, and move away from your hardcoded black and white 0% 100% statements (and thinking?), this limits productive collaboration and reasonable decisions where compromises might be better than a nothing or everything.
I'll make things perfectly clear.
I don't need nor want collaboration with DietPi nor you. Having to revert your commits that broke Pi-hole was the last straw for me. You don't know Pi-hole and you're trying to apply your ways to us.
I have asked you to not increase our support load by jumping in with things that will break and cause us more work to fix. You seem to be unable to abide by that and instead of understanding what I have asked, you respond with paragraphs of stuff I don't have time to read, nor the desire to read. I don't want your arguments and excuses, I want you to stop.
If you can not exercise the self-control to keep out of things that do not involve DietPi then please stop coming to our Discourse. If you can't do that, then we'll take care of it for you.
So, the choice is yours. If you can't handle that then you just won't be welcome here.
Yes, the RPI is using a static ip address.
I have not done any system (apt) updates, only 'pihole -up'
RPI Zero W connected using internal Wifi hardware with statically assigned IP.
Yes, carrier lost is occurring frequently:
grep carrier /var/log/syslog
Jan 31 02:07:28 pi-hole dhcpcd[450]: wlan0: carrier lost
Jan 31 02:07:29 pi-hole dhcpcd[450]: wlan0: carrier acquired
Jan 31 02:28:19 pi-hole dhcpcd[450]: wlan0: carrier lost
Jan 31 02:28:20 pi-hole dhcpcd[450]: wlan0: carrier acquired
Jan 31 02:44:30 pi-hole dhcpcd[450]: wlan0: carrier lost
Jan 31 02:44:31 pi-hole dhcpcd[450]: wlan0: carrier acquired
Jan 31 02:49:49 pi-hole dhcpcd[450]: wlan0: carrier lost
Jan 31 02:49:50 pi-hole dhcpcd[450]: wlan0: carrier acquired
etc etc