Forgive my ignorance -- what does this achieve?

That you can't have a bug in your code that lets an attacker overwrite data (aka a buffer overflow writes into memory) AND have that part of memory executed. It's either data (which can be overwritten) or code (which can't be overwritten).

It's not a fool proof mitigation for buffer overflow attacks, though. You can still write a bogus return address in a stack overflow and use return oriented programming (ROP) to do exploits with W^X. There are ways to work around address space layout randomization (ASLR) too.

No methodology in Infosec is every 100% prefect. You nest your defenses like Russian Dolls.

Each layer of protection fends off another class of attackers.

An attacker with infinite determination, money, or time will always push past your defenses.

in reality, at some point it's just not cost effective anymore (for the attacker) and other targets become more promising.

None of these mitigations is perfect. But how do you combine a exploit that has to deal with W^X, ASLR, randomized stack gap, stack cookie, randomized location of shared libraries and static programs. Seems pretty hard to me.

If an attacker is able to write arbitrary code through to memory, they won't then be able to actually execute that code.

It's a solid security enhancement.

Forgive my naivete, isn't that feature provided by the operating system?

Software has to play nice and not request WX pages. If they do, the OS does as its asked.

See also, Theo de Raadt's recent comment on why OSes can't enforce W^X on userland (yet): https://marc.info/?l=openbsd-misc&m=145943630726937&w=2

It is provided by the operating system, but you can't just naively enable it by default, especially in an application like Firefox (which has a JIT compiler for Javascript, and therefore needs to be aware of and able to manage which pages are writable and which pages are executable).