This is due to a missing "StartupNotify=true" line in the created .desktop file.
 It affects more than just the hourglass notification, however.  For metacity
2.9.x it also affects whether or not the launched application will be focused or
not (because the time of the launch of the application is needed for
focus-stealing prevention).

I'm bumping up the version number since I can verify it still happens under
2.9.x, and upgrading the priority/severity since it isn't just missing notification.

By the way, it would be nice too to have a visual effect similar to that of
panel launchers when opening stuff in nautilus (either launchers or documents).
I don't know if it's related to the present issue, but just for information it
is bug 147994.

Can nautilus reasonably do this if it has no idea whether or not
startup-notification actually works for the item in question? What's the side
effect if it doesn't? A startup cursor that never goes away?

The choice is between:
  a) make support for Gnome and other modern apps look bad
  b) make support for legacy apps look sub-par

(a) is current behavior (which will become much worse in 2.10 since
focus-stealing-prevention will fail and some apps will not even get focus when
they are launched--see bug 162424 for a closely related bug with more details
about this).  

(b) is the alternative which really isn't all that bad.  To answer Luis' questions:

The side effect is that a startup cursor that shows when the mouse is over the
desktop stays up for longer than one would expect, and then goes away after a
timeout (say 30 seconds).  startup notification launchers are required to be
smart and handle cases like this as best as possible.  You can try it yourself
to see exactly how things behave by running:
  /path/to/gnome/checkout/startup-notification/test/test-launcher \
    /usr/bin/xterm
It's slightly annoying, but not a very big deal.  I don't see why we'd want to
break decent applications because of a small issue like this with legacy
applications.

Okay, some qualifiers to what I said above:
  1) We could provide a "show hourglass when launching" checkbox in the
     .desktop file editor to help avoid problems (though it does sound like 
     clutter...)
  2) Actually, nautilus could cheat and set the DESKTOP_STARTUP_ID environment
     variable to "_TIME$LAUNCH_TIMESTAMP" to avoid the
     focus-stealing-prevention problems.
  3) Havoc has disagreed with me before on the
     default-to-using-startup-notification issue.  Probably still does...

Being more of an "advanced" GNOME user and not at all a developer, it is
difficult for me to get into the developers' shoes sometimes.  My comments may
seem harsh, but take them with a grain of salt, if you must; I'm only trying to
help.  That said...

Both options (a) and (b) above are unacceptable in my opinion.  A user does not
see the complicated matter that is involved with startup notification.  The fact
that, at times, there is absolutely no communication whatsoever to the user when
certain apps are being launched (certain is an important word here as it simply
adds more to the user's confusion).  This is a violation of the GNOME HIG which
states, "The user should never have to guess about the status of the system or
of your application."  If a user tries to open another app and receives no
feedback, they will assume the system didn't "hear" their click and will simply
repeat the action.  This obviously opens two instances of the same program.

But, if I had to resort to one of (a) or (b), I would go with (b), simply
because the user is receiving communication, even if it doesn't work perfectly
with legacy apps.  This issue truly needs to be ironed out though, and I'm
really surprised that more people haven't paid attention to it.  Startup
notification is handled much better in KDE, in my opinion.  Somehow, it manages
to accomplish an excellent level of communication with the user, and it seems to
work very well all throughout the desktop.

Some comments on the qualifiers....
1) Yeah, I think you're right that it would clutter the UI.  That wouldn't solve
the problem as much as it would poke at the symptoms.
3) Mr. Pennington may have a point.  However, I---and many other users that I
have observed and have been utterly confused and frustrated with GNOME all
because of this seemingly simple and rudimentary issue---am not buying into his
opinion on this one. 

Really, KDE appears to handle things much better?  Last I tried it, I thought
they were even more annoying about handling legacy apps launched with startup
notification (a much longer timeout, maybe 30 seconds or so whereas Gnome's
appears to be 15?).  But, maybe they have some guesses/hacks to better predict
whether or not to use startup-notification (e.g. run ldd on the executable and
search for gnome or kde libs, or other toolkits if any are known to support
startup-notification...)

Logan: You haven't heard Havoc's opinion, so writing it off is definitely
premature.  Especially since I haven't heard him state his opinion since we've
had the added issue of timestamps and focus stealing prevention to deal with
(which, in fact, is why I cc'ed him).

Elijah, you're right, I'm really sorry to have made that comment.  I got caught
up in the moment I guess and started pointing fingers in the wrong direction. 
Anyway...

This problem seems to reach further than I originally envisioned and I've
realized that there's really no quick fix that will be able to fix this issue (I
don't really consider it a "bug" anymore) by 2.10.

First off, you're right, the situation is NOT better in KDE, and many would
probably say it's worse.  If I had to choose between those two situations, I
would actually have to side with Havoc (if that is indeed his opinion), now that
I've thought about this harder and have played around with startup notification
a bit in GNOME and KDE.

However, I still think the whole startup notification thing in GNOME is
resolvable.  I'm going to write up a list of suggestions on how it can be
implemented and post it on gnome-list so that people can discuss this a bit more
and so that the issue can get out in the open (which I'm sure it has in the
past, but seems to be a silent issue lately).  But for 2.10... I really don't
think it can be solved by then, so instead of just sitting back and complaining
I'm going to try to help get this in the open so it can be worked out for a
future release.

I'm curious why people think I have a preconceived opinion here, I haven't ever
read this bug report ;-)

Here's an idea for a fix:

 - the "create launcher" form where you can fill in your own command line
   has a checkbox for whether to "show hourglass on launch"
or maybe
 - based on the Exec= line we scan known desktop files and try to guess
   the flag, or guess the default for the checkbox

But also, with either or both of those two options:
 - change 'create launcher' to by default offer a list of existing 
   .desktop files to use as the base a la Alt+F2, then have a separate tab or 
   disclosure triangle area for manual editing

So then the normal thing is "create launcher" -> choose existing .desktop file
And if you are custom-editing a launcher, you are responsible for sorting this 
out.

Logan: It's awesome to hear that you want to fix startup-notification and
.desktop files.  That's probably the biggest bug remaining with
focus-stealing-prevention (since it relies on startup notification being used).
 I was planning on trying to help tackle that more widely too, but haven't had
time to even look into it much.  I look forward to seeing your work.

Havoc: I said that you had an opinion on whether we should default to using
startup notification for everything and requiring legacy apps to manually state
if they don't want it.  And I said this because you have stated that opinion
before, e.g. at
http://mail.gnome.org/archives/usability/2004-November/msg00032.html.  ;-)

"It's awesome to hear that you want to fix startup-notification and
.desktop files."

Well I'm glad, but... remember that the stuff I said above about how I am "not
at all a developer" still applies ;-)

Have an extra suggestion. If would be nice if we could add a radio or toggle
button to the application that lets you edit .desktop file properties. I might
actually be capabale of this but I think it should be noted.

According to the summary, this is notabug, because we can't know if the target application supports startup-notification, see bug 549424 , I won't change this bug tough because the underlying problem is still unsolved.. 

Starting with version 3.28, nautilus will not handle the "files on desktop background" feature. For better alternatives, read this blog post https://csorianognome.wordpress.com/2017/12/21/nautilus-desktop-plans/