How do you know that the buffer is not narrowed?

Unless you have widened it right before you called the function, you cannot be sure. Moreover, "great software" is often defined as "being used in ways the author has never envisioned" - so one should always be prepared for the unusual use of one's code.

Code readability is King

When you write (goto-char 1), the person reading the code (including you 6 months later) will spend precious brainpower thinking

• "how do we know the buffer is not narrowed?" and
• "is the first character 0 or 1?"

Basically, unless you have (widen) right before, you need a comment explaining why you are confident the buffer is not narrowed.

Cost is trivial

Unless you have profiled your code and found otherwise, a safe assumption is that the cost here will be trivial. Compared to all the other things ELisp does (network, disk access, even string matching), (point-min) will not have a meaningful cost (and might even be cheaper, see Stefan's answer).

To complement sds's answer (with which I fully agree), despite appearances, (point-min) can be more efficient than 1. In terms of execution speed, my tests don't see any measurable difference, but in terms of size:

ELISP> (byte-compile '(lambda () (goto-char (point-min))))
#[nil "eb\207" [] 1]

ELISP> (byte-compile '(lambda () (goto-char 1)))
#[nil "\300b\207" [1] 1]

ELISP> 

That's because point-min has its own byte-code, and is hence encoded and executed very efficiently compared to other function calls.

Of course, another reason for me to use point-min is that I consider the historical choice of 1 to be a mistake (buffers should have started at 0).