It takes a lot to describe what's going on with A because it's a relatively new concept, related to the subject of the article. If partial application would be just as well known as function definition, the explanation could be shorter.
Only then do you get to learn those unnecessary gymnastics, so you can follow the rest of his code.
Fundamentally this is what programming is all about - finding the commonality that you can pull out and reuse, rather than doing every single case by hand.
The whole article makes sense as telling something new to the one who doesn't know what's the point-free style is - but might know what the partial application is. It's a feature, not a bug when something is learned as the result of reading the article and can be applied later.
There are many, many things that are /simple/ that are actually pretty hard to understand. Most of higher maths, for instance.
your idea of B being more simple is largely driven by the fact that you likely have more experience writing code in that manner. With experience writing functional code you should find that both A and B are clear at a glance.
B gives you all the information you need to know what's going on.
A requires you to go dig up what "partial" is doing (which, it turns out is itself doing some wacky gymnastics to turn one of its arguments into a function and the other into a parameter (and the parameter of whatever gets passed into the returned function as the other parameter of the function that was originally passed in).
Observe how much writing it took just to describe what's going on with your "A". No explanation at all is required for B. It's complete as written. Simple, and intuitive all in one.