The Postfix master process is the one that launches the other daemons. In particular, it launches the daemon that delivers mail locally; the latter must be able to impersonate any user ID in the system, which involves beginning its life as
root. Thus, it is mostly unavoidable that the master process runs as root; otherwise, it would not work at all.
Moreover, the "risk" involved in running things as root is often overestimated. For instance, on my own server, what I fear most is that my machine would be subverted and used as a relay for attacking other people. Whether an attacker gains root access or only a "normal user" access does not change things much in that respect.
There is a widespread habit of turning root daemons into non-root daemons, and then to rejoice at the "security improvement". The improvement is real in the mainframe scenario, where many users have shell accounts on the same machine, and the attacker is one of these users, intent on gaining access to the files of other users. However, the mainframe model has mostly disappeared (it used to be prevalent in universities, but nowadays every student has his/her own computer to play with). When machines are "personal" (e.g. you have your own server and no hostile individual has an account on it), the benefits of running some daemons under a non-root UID are slight. It does not harm by itself, but it does not justify going out of your way in complex ways to "fix root daemons".
What makes Postfix daemons secure is absence of buffer overflows or similar vulnerabilities; running as non-root is simply a way to mitigate consequences in case a vulnerability was present and exploited by an attacker; and the mitigation does not gain much when the machine is not a shared mainframe.