Mainly security reasons.
As I understand it, when a windows service creates GUI controls such as a MessageBox, they were normally only seen in the session that the services runs in ie Session 0 which also used to be the first user logged on locally or by someone logging on using mstsc /admin. Hence this user would see these controls and could interact with the service.
But for security reasons, Session 0 is now reserved and the first user to log on will be given a new session and hence not see the GUI Controls.
Since this breaks quite a lot of services, for compatibility, there is a process (see this MSDN blog) that attempts to detect if any messages are being displayed and popups with a warning 'A program running on this computer is trying to display a message' and allows you to view or ignore the message.
Microsoft have a WhitePaper on this subject which you can download from here
I would also suspect that another minor reason is because the feature was misused/misunderstood and led to bad designs. For example, I used to have an old server with a third-party service that displayed some notifications/errors using a message box rather than writing to the event log. But I never logged on locally and rarely logged in in admin mode and hence I would not see the messages.
Interactive services used to be possible, but the service model is that of a process that runs independently of any user. They are designed to be run unattended and therefore shouldn't need a GUI.
Interactive services haven't been available since Windows Vista so should no longer be used.
If you need to interact with the service the page I've linked to recommends creating a separate GUI application that communicates with the service through interprocess communication (IPC) of some sort - e.g. named pipes.
Because services are supposed to run in the background without interacting with the user; they may in fact run while no user is logged in.
Yes it was possible and it worked. When you logged in you got the interface of the application. It was very useful for older applications which don't have a service available but still need to run on the server. Though it was not the most stable solution. It became running as the user which could click it away or logout. That was not very nice.
Now everybody develops native services and adds an application or log to manage the service. That's a good design pattern and is now being used most of the time.
So see it more as legacy that it was possible.
The services are meant for un attended operations , mainly in the background.The name service itself means act as a server for some client applications or other services which consumes this service. So MS might want now to stick to the basics and want to draw some clear distinction between services and Apps.So apps keeps the uses busy and let services serve their purpose silently. While nail cutter is there why go for kitchen knife to cut nils?
