I know a couple of guys that would probably implement isLeap by checking that the lower two bits of the year are not set, then boast about how fast it was, and finally, when told that the logic was incorrect, push back because the additional checks would make it "slower".
In their minds, when things stop being simple, fast trumps correct.
One nuance is that some parts of correctness may be negotiable.
If I'm writing a file backup program, it absolutely must back up all the files without leaving any out or corrupting the data.
But let's say it has a feature that prints progress indicator percentages on the command line, ranging from 0% to 100%. Maybe under certain circumstances (like files added to a directory after the backup starts), it prints 102%. It's not what I had in mind, nor is it something I'd call correct. But if fixing it complicates the code a lot, maybe leaving it that way is the better choice.
(This is a bit of a contrived example because you could just clip the value at 100, but you get the idea.)
You missed the point of the article if you interpreted it as correctness being intentionally sacrificed for simplicity.
Plus, a complete leap year implementation is already what I would consider simple and most standard libraries already have an implementation for it you can use directly.
I don't think simple means discard if complex. It means using the simplest and most obvious tools (algorithms, libraries, &c) possible in order to achieve a correct enough software. So it does not mean discarding intricacies of timekeeping, but implementing it with the clearest, simplest use of abstractions and methods possible.
In their minds, when things stop being simple, fast trumps correct.