There is a subtle, but important difference between the two sets of tools. I know this is subtle from a users point of view when all you want to do is import or export the database! But the two samples are meant to be examples for different scenarios.
Remember the code is there for you to play with and customize to your scenario.
The client side tools require DAC and other framework components to be installed, and run on your machine. That is during an import or export your machine is connected to either the local SQL Server, or SQL Azure and is working with a local bacpac
Pros are that you can work against local servers. And you can even take a bacpac generated from the service and import it back to your on premise database.
Cons are that your machine has to be installed with the components, and that the machine is actually doing the work. If the machine drops the network connection your operation is terminated.
The service tools do not require any of the DAC components to be installed on your machine (only .Net 4), and only submit jobs against a service that is running in Windows Azure. Then the actual import or export is performed on our servers, your client
can be turned off and it does not matter.
Pros are that you do not have anything local, and your machine is freed up from being connected during the operations. This tool is also xcopy deployable and has no dependencies on the DAC framework.
Cons are that you have to put your bacpac in a blobstore first, and it does not work with on premise databases.
A single combined tool?
Could you make a single combined tool that changes based upon input? Yes. But that was not the goal here. One is to be lightweight (xcopy deployable), while the other is to support a wide range of Sql Servers.