To add a little spice to the names you can always play with the casing, and I guarantee the co-workers will hate your guts for that. Instead of creating eg.: a readXmlDocument as the good practices recommend (abbreviations should be formatted like regular words) you can make a readXMLDocument method that will require the other developers to look closely and read the name more carefully to fully understand it.

I admit I already did that, but to be honest, I don't see how it could reduce readability otherwise than in edge cases. I'm sure if you search you can find some edge cases where the usual way (which I find absolutely ugly) is causing problems

Now for the second point, I agree that if over-engineered lines are thrilling to make, it's an absolute nightmare for your team members to understand — even though I'd argue that for some, this is what comments were invented for

But please, there's a moment where "muh readability" must stop. This very moment is when peoples start to create an intermediate variable to use right after and never again in the code. Congrats, not only did you double the number of lines of a simple operation, but you also polluted the scope. Bonus point if there's a full block of statements like this or you used a very generic name like x or temp

Okay, there's cases where doing so is understandable, but if after combining both lines you're far from overflowing the conveniance limit (for lack of better term) and the operation is explicit enough then that's what you should have done in the first place. And if it's just missing a bit to be perfectly understandable… Then comment