Processing card input is among the most basic functions COBOL had to provide to get a hold in data processing - computers were meant to be integrated and improve existing card procedures.
Now, reading past the citation gives Ms. Sammet's impression:

I would think that the use of 'inappropriate' does indicate that the mentioned 'direct processing' of card input is something quite out of the intended scope of COBOL.
COBOL is all about machine independent processing of (decimal) integer and text. The later mostly by moving and comparing. To comply with this important goal, the language itself does not define a specific character set to be used, nor does it provide any way of binary manipulation of characters. All input or output was always thought to be opaque characters - not to mention, that back then most, at the time, were printable anyway - the number of non printable characters was, at the time, essentially zero.
With this in mind, the request of 'direct processing of card files' could refer to being able to read cards as image (aka the holes), instead of characters (*1). It's obvious that this feature could be useful to read 'foreign' (*2) data - while at the same time may introduce many possible ways to break code and programs, making them quite machine dependent. It is easy to see why this proposal might have received a lot of flak.
This interpretation gets some support when looking at the way how FACT (*3), Honeywell's business language, defined fields in terms of a mode specifier that included lots of punch card based definitions, leaving a lot of machine specific interpretation.

More so the input definition allowed not only the mane types for each column/field, but enabled definition of quite complex relations including redefinition of characters. For someone familiar with the way punch cards were used before computers and during early computerization, this may come extreme handy to read and process 'unusual' cards - like all the variant combinations users had make up for their specific purpose ... never underestimate the creativity of a user to find use cases for an additional hole or two :) (*4)
Just a guess considering the time, history and general workings in the punch card age.
*1 - Optional even the ability to manipulate these data (on 'hole' level) and output arbitrary images again.
*2 - in the early days of computerization next to every manufacturer had their own extensions to basic punch card encoding. While numbers, signs and letters were set, everything past that was up for grabs.
In addition, customers as well nudged card use for their purpose. Need a way to encode the department in a single column? Just make up a combination not used so far!
*3 - IMHO COBOL inherited way more from FACT than from any other language including the often praised FLOWMATIC.
*4 - In fact, this wasn't restricted to punch cards. In the mid 1980s (!) I met a blind lady using ED under CP/M to manage all her office data. Operating with a braile line ED was a perfect tool, and she was rather creative to use this in a way reminding of punch card computing. With the keypad she had, every 8 bit input could be created, so she invented combinations for common items like field names or abbreviations for Mr/Ms/etc. She had to memorizse to key combinations for letters anyway, so that were just additional letters to her. In contrast, her secretary had to learn that some Polish Ł
meant Mr. while a Spanish ñ
symbolized Ms. :)