Arch Linux

Works fine for me.

$ uname -r
4.20.0-arch1-1-ARCH
$ sudo nmap scanme.nmap.org
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-31 14:15 EST
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up (0.097s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp filtered smtp
80/tcp open http
9929/tcp open nping-echo
31337/tcp open Elite

Nmap done: 1 IP address (1 host up) scanned in 5.97 seconds

Can you try the same on the local network? That is the case when nmap uses arp and not ping for scanning.

That is a good point, but still no.

$ sudo nmap -PR 192.168.1.0/24
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-31 14:41 EST
Nmap done: 256 IP addresses (0 hosts up) scanned in 0.04 seconds

What wifi card do you have?

Can confirm the behavior:

As root:
# nmap fritz.box
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-31 21:04 CET
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=22: Invalid argument)
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=22: Invalid argument)
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.58 seconds

As a regular user:
$ nmap fritz.box
Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-31 21:03 CET
Nmap scan report for fritz.box (192.168.178.1)
Host is up (0.014s latency).
Other addresses for fritz.box (not scanned): ... ...
Not shown: 995 closed ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
443/tcp open https
5060/tcp open sip
8181/tcp open intermapper

Nmap done: 1 IP address (1 host up) scanned in 0.30 seconds

My WiFi hardware:
04:00.0 Network controller: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter (rev 31)
Subsystem: Lenovo QCA9377 802.11ac Wireless Network Adapter
Flags: bus master, fast devsel, latency 0, IRQ 70
Memory at c0200000 (64-bit, non-prefetchable) [size=2M]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/8 Maskable+ 64bit-
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [148] Virtual Channel
Capabilities: [168] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [178] Latency Tolerance Reporting
Capabilities: [180] L1 PM Substates
Kernel driver in use: ath10k_pci
Kernel modules: ath10k_pci

I have the same problems with few different interfaces on two different computers.
Both computers:
4.20.0-arch1-1-ARCH #1 SMP PREEMPT Mon Dec 24 03:00:40 UTC 2018 x86_64 GNU/Linux

Network cards:
lspci:
24:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 3e) - iwlwifi
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) - r8169
03:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network Adapter (PCI-Express) (rev 01) - ath9k
lsusb:
Bus 001 Device 002: ID 2357:0122 TP-Link - 8812au

I cannot reproduce this issue myself.
Ivan and AK, could one of you please report this upstream? See: https://nmap.org/book/man-bugs.html and https://github.com/nmap/nmap/issues/
Cheers.

Same problem here

As root:
# nmap internetbox
Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-01 21:38 CET
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=22: Invalid argument)
WARNING: eth_send of ARP packet returned -1 rather than expected 42 (errno=22: Invalid argument)
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.57 seconds

As a regular user:
$ nmap internetbox
Starting Nmap 7.70 ( https://nmap.org ) at 2019-01-01 21:36 CET
Nmap scan report for internetbox (192.168.1.1)
Host is up (0.012s latency).
Other addresses for internetbox (not scanned): 2a02:120b:c3e2:...[cut]
rDNS record for 192.168.1.1: internetbox.home
Not shown: 997 closed ports
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
49152/tcp open unknown

Same reply to you, then: please report this upstream.

Reported upstream by NBaH2, see https://github.com/nmap/nmap/issues/1423