1. no, I'm sure "support" for untrusted certificates will stay
   Note that self-signed certificates are nothing special ... except for the fact that client can not link certificate through trust chain to a trusted top-level certificate. List of trusted top-level certificates is either part of browser suite or is part of OS, current implementations of both allow to install additional top-level certificates by hand.
2. if you install certificate of self-signing CA to browser, then browser will automatically trust certificates issued by self-signing CA. With locally generated certificates that will never happen. However, creating certificates and signing them with self-signing CA does mean some (manual) work.
   When installing certificate, created off-device, it is vital that private key is transferred to device via safe connection ... if it's read by man-in-the-middle, then certificate is compromised and thus useless. With locally generated certificates copying private key is not necessary.
3. with long-lasting certificates it's more likely that "man in the middle" finds private key of certificate and starts to decrypt communication. And do it as long as certificate is still valid.
   Another danger: if certificate gets compromised and you establish automatical trust in certificates issued by a CA (doesn't matter if it's self-signing or some well-known), then you'd have to deal with certificate revocation mechanisms. If certificate validity is short, then you might live without it (because validity after certificate compromise would be short anyway).
4. basicaly you perform all the steps you do for new certificate. Basically steps are:
   1. create private key
   2. create certificate signing request (CSR), which already includes CN of server that will use certificate. CSR also includes private key hash.
   3. CA signs CSR ... or in other words, issues certificate. Certificate validity is set at this step.
   4. both signed certificate and private key are installed to server which then uses certificate.
   When renewing certificate, in theory it should be enough to perform steps c. and half of d. (private key is the same, certificate is different), but that would increase probability to find the private key (as mentioned in answer #3 above). So in practice certificate renewal includes all the steps taken for new certificate.
5. IPsec tunnels, ...

Only a couple of Linux PCs (from sysadmin team) will ever need to access WebFig.

Then make your life easy and forget about certificates and https. It's not that they are too difficult, but it is some extra work, and I don't see how they can add anything for your use case. Allow only ssh, and if someone wants WebFig, they can use ssh port forwarding to access it. Since ssh already provides encryption, WebFig can use plaintext http and it will be still perfectly secure.