tftpd [-V] directory
directory is required argument; if it is not given tftpd aborts. This path is prepended to any file name requested via TFTP protocol, effectively chrooting tftpd to this directory. File names are validated not to escape out of this directory, however administrator may configure such escape using symbolic links.
It is in difference of variants of tftpd usually distributed with unix-like systems, which take a list of directories and match file names to start from one of given prefixes or to some random default, when no arguments were given. There are two reasons not to behave in this way: first, it is inconvenient, clients are not expected to know something about layout of filesystem on server host. And second, TFTP protocol is not a tool for browsing of server's filesystem, it is just an agent allowing to boot dumb clients.
In the case when tftpd is used together with rarpd(8), tftp directories in these services should coincide and it is expected that each client booted via TFTP has boot image corresponding its IP address with an architecture suffix following Sun Microsystems conventions. See rarpd(8) for more details.
Impact is evident, directory exported via TFTP must not contain sensitive information of any kind, everyone is allowed to read it as soon as a client is allowed. Boot images do not contain such information as rule, however you should think twice before publishing f.e. Cisco IOS config files via TFTP, they contain unencrypted passwords and may contain some information about the network, which you were not going to make public.
The tftpd server should be executed by inetd with dropped root privileges, namely with a user ID giving minimal access to files published in tftp directory. If it is executed as superuser occasionally, tftpd drops its UID and GID to 65534, which is most likely not the thing which you expect. However, this is not very essential; remember, only files accessible for everyone can be read or written via TFTP.
It is distributed with iputils mostly as good demo of an interesting feature (MSG_CONFIRM) allowing to boot long images by dumb clients not answering ARP requests until they are finally booted. However, this is full functional and can be used in production.