Is it necessary or advisable to teach text-based input and output in a non-CS intro programming course? I teach an intro programming course in a social science department. My field is geographic information systems. The goal for the course is for the students to understand scripting in an interpreted language so that they can automate analytical workflows or add custom functionality to off-the-shelf software. The language we use is Python, but the question is more general than that.

Programming languages have some way of obtaining input and displaying output. There is a long tradition in computer science of starting with "Hello, World!" as a basic program that produces output. Additionally, output statements can be used to display the state of variables for debugging purposes. Introducing input and output is common in computer science textbooks (Think Python 1.3 The first program) as well as domain specific texts such as the one that I use for this course.

The problem I am running into is that beginning students can't seem to unlearn this after we move on to new material. Throughout the semester they turn in assignments that are littered with unnecessary print statements. These are "harmless" in the sense that they don't alter program logic, but make for sloppy code, and are perhaps not harmless if the students think that they need to do this and don't transition to, for example, using the IDE for variable inspection as they code.

Q. Is it necessary or advisable to teach text-based input and output (e.g. Python's input and print functions) in a non-CS intro programming course?

Is there pedagogical value? Does it teach something necessary? If so, can it be delayed? What are the alternatives, or is there no alternative?
I've been coding for 20 years in non-cs fields. I've worked on several >100k line code bases. 

Almost every program I write comunicates with the outside world via text, usually a file hand or file-handle-like connection to stdin and stdout. 

In addition, I also almost exclusively  do my debugging via print statements (or output to debugging logs). 

IDEs and graphical debuggers can be very useful tools, but they can become a crutch that excuses the student from thinking. Print statements encorage the student to really reason about the logical and flow of their program - they must be able to hold the program in their mind and understand where it is going to be important to output a variable state, or just ping "here" to the terminal. 

Now obviously I wouldn't insist that students must do this when working on large, complex code bases, but while they are making simpler things, things where holding the whole structure in your head is possible, then I think it is good for them.