All CPU-intensive tasks launched by the application occur on the server, saving energy, computation, and memory resources on the client. This was ideal in my use case: the typical client (my laptop) has limited memory and a slowly dying battery; any opportunity to offload computations to the much faster server was a good opportunity.
These programs (think Microsoft Office and the Adobe suite) require a significant amount of disk space to install. SSDs still have comparatively limited storage space, so the ability to use these applications with zero additional disk usage on the client was a huge plus.
Microsoft's RDP protocol is fast. RDP does a fantastic job at separating the role of core CPU tasks required for the application to run (which occur exclusively on the server) and the role of rendering the application's graphics for presentation (which occurs exclusively on the client). This is both faster and more flexible than, for example, VNC, which directly transmits graphics rendered on the server over the network to the client (ever check the bandwidth usage of VNC when transmitting best quality?).

The ability to use these RemoteApp applications required the client to be connected to the Internet. This was acceptable to me--I reasoned that only on rare ocassions do I need to do serious work and not have some kind of network connection.
The seamlessness of the experience depends entirely on the quality of the network connection. Latency between the client and my Los Angeles-based server is over 500 ms? Forget it--RDP is fast but when your network sucks, everything takes a hit.
The client filesystem needs to be forwarded (over the network) to the server in order to work on local files. This is not necessarily difficult to do (most Windows and Linux RDP clients support some variant of local drive redirection), but, as one might imagine, working on files in real-time over a network (much less over the Internet) can be painfully slow.

I installed the Active Directory Domain Services (ADDS) role on the server, then promoted the instance to a domain controller, following this guide. Microsoft misleadingly may have you believe that the domain controller role cannot coexist with the Remote Desktop Services role, but this restriction applies only to Windows Server 2012, and not Windows Server 2012 R2. Even then, Microsoft later added support for the coexistence of these two roles on Server 2012 with a simple patch.
After the server was promoted to a domain controller, I installed the RDS role on the same server. In Add Roles and Features in Server Manager, go to Remote Desktop Services Installation. Quick Start was sufficient to my purposes, and installation finished without incident.
At this point, if you go to the RemoteApp configuration panel of the Remote Desktop Services pane in Server Manager, you have the option to "Publish New RemoteApp Programs" as one of the action items under Tasks. In my case, all of the Microsoft Office and Adobe suite was available for me to publish.
My Linux RDP client was rdesktop, which didn't have support for CredSSL. To remedy this, I went to Computer > Properties > Remote Settings, made sure that remote access was enabled, and unchecked the box requiring clients to use NLA.
Lastly, port 3389 (RDP) needs to be open in the firewall so that clients can connect. In Windows Firewall Advanced Settings, add both incoming and outgoing rules to allow TCP/UDP port 3389. If you're behind a NAT, you might need to port forward 3389 to expose it to the Internet (alternatively, you could tunnel the port through SSH, which would be more secure but also add additional latency and overhead).

HOSTNAME is the name of the Server 2012 R2 host. In my case, it would be solara-vm.ad.kevinlin.info.
USERNAME is the username of the user on the server who has access to the RemoteApp programs.
ADNAME is the name of your Active Directory tree, which you set when configuring the ADDS role on the server.
APPLICATION_NAME is the alias for the RemoteApp program you want to execute. In the RemoteApp configuration panel of Server Manager, you can find the alias listed next to each published RemoteApp program. Generally, it's the name of the program executable.
WIDTH and HEIGHT correspond to the width and height of the window rdesktop will initialize for the RemoteApp program. You might, for example, pass -g 1920x1080.
SHARE_NAME is the name of the share that will be available on the server that redirects to a local directory on the client. You could, for example, call this clientfs.
LOCAL_PATH is the path on your local filesystem you would like to expose to the server. For example, if you passed -r disk:clientfs=/home, when browsing files while in the RemoteApp program, you would have access to a share called clientfs that redirects to the /home directory on the client machine.
-p - will interactively prompt you for the password for ADNAME\USERNAME.

function remoteapp_func() {
    rdesktop HOSTNAME -u USERNAME -d ADNAME -s "$1" -g WIDTHxHEIGHT -r disk:SHARE_NAME=LOCAL_PATH -p -
}
alias remoteapp=remoteapp_func

$ remoteapp photoshop

Website

Github

Twitter