Well if you really want a reason to hardcode it then I guess there is one. In extremely performance-optimized games like Quake 3 they wrote the internal VMs (not the exe-file, this one was built "normally") without including ANY C library. So since they also didn't use malloc (actually they rewrote this function on their own, using pre-defined buffers) or any form of dynamic memory allocation then certain text has to be tailored to the machine/setup. So if you're insane enough to value 1 or 2 CPU cycles or those few saved kilobytes of memory more than good/flexible script then there you have it.

Most games ive worked on the text is embedded in the scripts but in the form of a code tag which references an external data table which load the text on demand, so both is correct to some extent. If your writing a game you don't want to go crazy and make the entire dialog system completely data driven (unless that's your plan), that's usually a bad fit. The logic which triggers these dialog and what dialog options available are encoded in the scripts, the only thing is the raw text itself it not hard coded into the scripts rather they are held in a giant dialog table externally usually in some spreadsheet form. You can also embedded other information with the dialog text which u can extract as well, such as wild card and the like etc..