The Windows Update user interface simply gave the useless 80004005 error, but detailed information about the failure was available in c:\windows\logs\cbs\cbs.log:
2017-12-28 20:54:05, Error CBS Failed. Attempted to uninstall a version of a non-driver component that is not installed, version: 0X700061db15cfe, component: amd64_microsoft-windows-w..lient-aux.resources_31bf3856ad364e35_7.6.7601.23806_en-us_e79af1b12d6db6c9, owner: Package_835_for_KB4022719~31bf3856ad364e35~amd64~~6.1.1.6.4022719-2919_neutral_LDR [HRESULT = 0x80004005 - E_FAIL]
Each update is a package which refers to many other packages, like Package_835_for_KB4022719~31bf3856ad364e35~amd64~~6.1.1.6.4022719, and each of those packages refers to components, like 2919_neutral_LDR. If you're curious, you can unpack an update and look inside it. First unpack the .msu to get the CAB and then unpack the CAB. You probably must use Microsoft's expand.exe to unpack the CAB because it may use intra package delta (IPD) compression which is not supported by 7-Zip.
Inside the CAB you will find various .mum files, which correspond to the main package and those sub-packages. The logical thing to do would be to reinstall these problematic components. However, I don't see a way to install from a .mum file.
So, I ended up uninstalling the messed up update by editing its already installed .mum file, found in c:\windows\servicing\packages, as package_for_kb4022719_sp1~31bf3856ad364e35~amd64~~6.1.1.6.mum. (Note the absence of a number after "package" in the file name.) That directory is set up by default so only TrustedInstaller can write there. Not even SYSTEM can write there! So, I had to temporarily grant access to Administrators. The sections to remove are like this:
<update name="4022719-4117_neutral_PACKAGE">
<package integrate="hidden">
<assemblyIdentity name="Package_835_for_KB4022719" version="6.1.1.6" language="neutral" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" />
</package>
</update>