Delta Time In Game Design

To come back to the original question.

How many of you, those who release games to stores, implement delta timing in your games?

Using GMS.. I don't.
Using Unity. I do.

When removing the fixed frames. You have to re think the way you use the engine, you can no longer rely on image_speed, speed, timeline_speed, alarm[], gravitry and overall general physics.
you need to update your own x and y update with your own speed factor, recreating a physics abstraction layer.

You can no longer ask "am I colliding with object x". There's no testable determinism so you might end up going through the objects at some point. place_meeting is not relevant anymore, You need raycasting for that, most of the collision offering from gms become useless as you start recreating a new collision abstract layer.

You can no longer assume moments. If your delta is too long you may end up skipping over a few events, you need to detect when to trigger based on time. So you can't rely on the GMS's moment and alarms system anymore and have to recreate a new trigger abstraction layer.

And a few sparse cool bug/feature. While playing your delta timing game in window mode (not fullscreen) Start dragging your window around, which pause the processing, you will see interesting delta spikes and you will see your walking toon teleporting through walls. Unless you cap your delta and workaround that pausing effectivly recreating a fixed frame rate and pausing mechanism.

While developing, your delta timing will mostlikely be bellow the 4ms critical mark... After all those efforts you will realized you actually created/tested a game which offer crappy experience on a 7th gen i3 core typical 3 years old laptop

Now you go into the original question...
Is it a monetary viable solution to recreate the nuts and bolts before assembly? It's highly arguable and has nothing to do with any technical points, you need to put the $ in there to do the math.

Do you want to align with GMS's core abstraction with embedded decisions toward fixed frames. Or do you want to extend that offering to offer something unique.

2D Casual games will usually go just fine with 60hz, that's what your target audience's none-gaming computer and laptop support anyway.
You want to hit the TV market with uwp? fixed 120hz will be just fine..
You want to hit the android target? fixed 45hz will be just fine..
You want to hit HTML5 target? 30hz ... now this one is tricky... i'll save it for anothe debate.
You want to monetarize true-3d at 144hz? I question GMS to be the right solution.
You want to learn/try/poc about true-3d at 144hz on GMS? Yeah .. why not.

--
Now let's come back to that Desktop conversation... let's forget about about html5 or mobile for a second.
60hz is just "fine"
But 60fps is too slow... I favor 120fps for modern desktops.
Just like I used to favor 60fps / 30hz decades ago.

Decoupling rendering and update is not a new concept and it's inheriently part of GMS's offering so you don't have to fight against it.
You don't even need 2 clocks, you just need to alternativly turn off the expensive draw event (everything from pre-draw to post-draw)

Why on earth would I say 120fps that's such a weird number?
It has nothing to do with rendering to be honest, it's just 60*2 for conveniance (and the UWP target forxbox one)
It's all about input lag.... the ideal fps would be 240+fps... but that's waaaayyyy out of my reach.
120fps? yeah that's a good compromise I can easily reach on a 7th gen i3 typical laptop.

if you run your game update at 30fps. It means your input are processed every 1000/30 = 33ms...
Mouse and Touch? You won't see the difference...
Keyboard and Gamepad? You can feel it! it's annoying. If feels like the game is not reacting to your inputs.

if you run your game update at 60fps. It means your input are processed every 1000/60 = 16ms...
It used to be ok... more and more casual player have now experiences the faster update rate.. it becomes a little bit more of an issue.
When you hear people saying 144hz is more responsive than 60hz... that's actually what they have in mind.. nothing to do with visual really.

Players often prefer to keep the fps high for their games and if their hardware can't support it, they will often prefer to cut on the visual features, removing shadow, removing lights, reducing resolution, before they cut on fps.
For games where fps=hz that basically means a crappy visual / crappy responsivity tradeoff.

if you run your game update at 120fs. It means your input are processed every 1000/120 = 8.3ms...
You are now pretty well aligned with typical wireless devices. and USB2 interfaces.
The game feel smoother even on an 60hz monitor.

240fps.. you get the gist.. 4ms input lag becomes virtually unnoticable.

--
Now that's where frame skipping comes into play.

at 120hz you are losing so much processing power on preparing renders that won't be displayed on that icore3 laptop...
Might as well just decouple render and update to support 120fps with 60hz. skipping draw events (draw_enable_drawevent ) every alternating frames.

I do have to agree tough.... All my assumptions are based on the fact you are deploying 2D games when using GMS and you scene does not change on every single pixel at every frame.