I'm looking for a design principle referring to using a system for it's intended purpose

Just repeating the link I put in the comment:

en.m.wikipedia.org/wiki/Lawoftheinstrument

The Wiki page shows a number of related terms and areas of application.

Using a tool for an unintended purpose is hacking. Hacks are not necessarily bad. But a hack has all the same risks as designing the tool in the first place.

Using bespoke tools has the benefit of leaving those risks for the designer to assume. When you hack, you take on that responsibility.

So you can use a screwdriver as a pry bar or go buy a pry bar. Either way it can go wrong. When it does you may need to explain yourself. It’s about what you’re comfortable being responsible for.

One factor to consider is legal liability. Say the tool malfunctions, it deletes, alters, or duplicates reports, could you get sued? Or incur other penalties or damages? If so, could you sue the tool provider in turn to recover damages?

Chances are that an off the shelf tool assumes the least amount of legal responsibility they can. If it goes to court and it decides that whatever tool you are using is inappropriate there is a chance that the penalties will be higher.

This is a common consideration for medical software and other medical devices. In this case the documentation should state the intended use, and any "of label" usage shifts the liability to the doctor or patient that decided on that usage. I would expect a similar situation in other areas with highly formalized rules.

The employee can use the survey tool, which produces cost X and benefits Y. If your company uses the survey tool already, and the drivers use it already for surveys, the cost may be low or zero.

Or you buy or create a new tool specifically for that purpose. That will have more cost, including training cost for the drivers, and may produce more or less benefits.

You pick the method that maximises benefit minus cost.

Is there a well established principle that states that using a tool for an unintended purpose is bad, and explains why?

"Every fiber of my being screams" ... requirements. First, read this book:

201 Principles Of Software Development by Alan M. Davis. I. Love. This. Book. Organized into sections each principle has a one page treatment. There are 23 requirements principles for example. Concise and pithy these will get you going.

Second, maybe you can talk up how this (inappropriate) tool is a prototype. If anything seeing where this tool falls short is a great way to discover requirements.

Is there a well established principle that states that using a tool for an unintended purpose is bad, and explains why?

Requirements is software principle and the explanation. Specific needs for a specific problem. Solutions are assessed against the requirements which tends toward avoiding the "hammer-nail" pitfall; a mistake but not a software engineering principle.

There is a psychological effect describing the power of habit that could spring the principle of "use the right tool for the job", the effect is called Eistellung effect:

Einstellung (German pronunciation: [ˈaɪ̯nˌʃtɛlʊŋ] ⓘ) is the development of a mechanized state of mind. Often called a problem solving set, Einstellung refers to a person's predisposition to solve a given problem in a specific manner even though better or more appropriate methods of solving the problem exist.

                                                                                                                              _{(according to wikipedia)}

When a way of acting tuns to a habit it is going to seem the right tool for every job, it can also resemble the psychological prison that the attempt to escape from it tuns it to psychological clojure.