OK, I think I'll directly create a task, because I don't believe that using padding-bottom for paragraphs was an informed decision. Context: T360917, T352875, T351754, etc.

This task was partly inspired by T352875#9674743 by @Xover, in which they said:

Please don't use tricks like combining margin-top and padding-bottom. You're doing it to defeat margin collapsing, which is how the CSS box model is supposed to work.

for a project like Wikisource that actually needs to vary this stuff from page to page doing this just makes it feel like the skin is fighting us every step of the way. I can deal with the 7px (.5rem) top and bottom margin if it's consistent across Vector 2010/2022, but a completely different way to achieve the effect between the two, with different values, and in a way deliberately designed to defeat basic box model behaviour…? Now I just want to throw a complete style reset in MediaWiki:Common.css and call it a day.

The whole idea behind using margins, not paddings, for elements in text flow is that margins collapse, i.e. the bottom margin of the upper element overlaps, partially or entirely, with the top margin of the lower element. This allows to have stable margins between whichever elements. E.g.: tables have 1em margins while lists have 0.5em. If you make them adjacent, table + list or list + table, tables will always have 1em around them, not 1.5em and not 0.5em.

With padding, there is simply no way you can ensure stable vertical margins in a text flow for elements of a certain type (which is how it's supposed to be designed), unless you either

1. use some incredibly dirty rule like p + * { margin-top: 0.5em }, which defeats the whole idea of fine-tuning margins in a way your design suggests;
2. or hardcode every possible combination of siblings, e.g. p + ul, p + pre, p + blockquote, p + table, and so on (we already have tasks for three of them, and there is no point in creating one for each of the rest).

And even if you do any of that, you will be left with nested elements, which the margin collapsing mechanism also covers but padding does not, so you will have to add even more ad hoc rules like p + div > table, the potential number of which approaches infinity. And then there are empty elements, which the margin collapsing mechanism...

If you decided to refrain from using simple margin: 1em 0, which would ensure even margins, then instead of using padding-bottom: 0.5em for p , you could use margin-bottom: 1em and a negative margin for the next sibling in exceptional cases, e.g. p + ul, p + ol { margin-top: -0.5em }, together with :first-child / :last-child pseudo-classes as required. Other options might exist which I'm unaware of.

And I don't even mention the sheer volume of CSS readjustment that all wikis are now having to undergo, which was the central part of @Xover's rant and the subject of several tasks, many more to come.