First of all, with V6, there is no architectural limitation on where you place the Veeam server, it can be placed at either the source or destination site with no impact on the replication. The important thing for replication is the location of the proxies and repositories. For V6 there should always be a proxy at both the source and target, and there should be a repository located on the source side (the repository can the the same system on which is used as the proxy for the source side).
If you feel better having the Veeam server available after a complete loss of the source site, then you should by all means place the Veeam server in the DR site. If the Veeam server is being used only for replication (not backups) this is actually the "best practice".
However, if the Veeam server is being used for both backups and replication, it might be better to keep the Veeam server at the source location since a network outage would cause local backups to work. For some customers, the best solution is to have two Veeam servers, one in the source site to handle backups, and a second in the target site to handle replication. This has the advantage that there is a server in the DR site to perform failover, and also to use for backups once a failover has taken place, an issue often overlooked in the DR design.
Manual failover is generally suggested only as a last resort because this does mean that you would loose some of the features such as Re-IP, however, the process overall is very easy since the VMs themselves are native VMware VMs simply waiting to be powered on. Even in the event of a complete manual failover you can still failback relatively easily by using replica mapping.
Having a good replication design is important and it's good to see that you are thinking about all of the options and possibilities. Veeam provides a lot of flexibility in it's approach here. For a physical solution you can place the Veeam server wherever you like, source or target, you can virtualize the Veeam server itself and replicate it, using the physical server as a proxy, you can use SQL native replication, you can use SQL native backups to backup the database/transaction logs to the remote site. It's all based on your goals and desires.