Also like pornography, I think most of us would disagree at least to some degree.
Details matter, sometimes by a great deal. A coworker and I raise objections and ask for clarifications a hundred times a day in the course of our work, and more often than not at the end of that day we discover there are still important details that are missing or incorrect.
Sometimes these so-called "inconsequential details" are what will ultimately sink a project, and in spite of our captious nature the project will try to sail out of the harbor regardless.
[Edit]
Since there seems to be a lot of disagreement on this matter, I'd like to take another stab at exactly why I feel like the article is incorrect.
If a colleague is finding a lot of faults in your idea, that should say two things to you assuming you have respect for your colleague and value their opinion: one, that your colleague has a genuine interest in your idea and is trying to think it through from various angles to find what areas of it need refined; and two, that your idea is in need of refining and you should probably be taking notes.
If, however, you do not have any respect for your colleague, you may dismiss their comments and criticisms and simply call them "captious".
If there is an established cycle of this scenario then there are three possibilities: that you have a lot of ideas that are worth consideration and polish, that you have a lot of bad ideas and lack enough of an understanding of the subject matter to determine what constitutes "petty", or that your colleague has personal issues that need directly addressed. This is how it should and often does play out in the real world.
In the author's scenario, which ironically enough takes place in a classroom, the old adage of "there is no such thing as a stupid question" seems to have been disposed of. They have narrowed the definition of "captious" to target individual issues, which in any normal context would otherwise signal that the person in question is lacking in understanding. Worse still, they are given a "shame hat" for doing so.
You know what sort of fictitious conversations sprung to my mind upon reading this?
Adobe Engineer: We should use bcrypt to secure our users' passwords, it's scalable and processor intensive so it's more secure.
Adobe Middle Manager: Or we can use this other encryption protocol and save on server costs.
Adobe Engineer: But that's encryption, not hashing, we shou-
Adobe Middle Manager: Same difference, stop being captious.
Petty details, indeed.