I think it's some sort of interaction between the position: absolute;

#coordinates {
  position: absolute;
  top: 0;
  right: 0;
...

on <span id="coordinates">, and the position: relative;

.vector-body {
  position: relative;
  z-index: 0;
}

on <div id="bodyContent" class="vector-body">.

When the content is rendered in the realtime preview div

<div class="ext-WikiEditor-realtimepreview-preview mw-preview-loading-elements">

the #coordinates span loses its positioned ancestor (the realtime preview div) and instead uses the document body.

Quickly hacking in position: relative; on the realtime preview div

<div class="ext-WikiEditor-realtimepreview-preview mw-preview-loading-elements" style="position: relative;">

seems to fix this, but could well cause other problems..

Why is CSS like this?

The best solution is likely the same as for T281974: Fix alignment of coordinates and page indicators (Vector 2022): use an indicator instead of CSS positioning in the coordinates template.

The long-standing Live Preview has a similar issue:

{F35216438}

At any rate I agree with JJMC89. This is an editorial problem will likely manifest itself in various ways as we increase the rollout of Realtime Preview (coordinates aren't the only things out there that position absolutely within the content area). Usually it's something the community will have to fix, if they want to. Still good to log this issue but I wouldn't personally consider it an issue with Realtime Preview.

I see a similar bug with commons shortcuts, e.g. https://commons.wikimedia.org/w/index.php?title=Commons:Media_of_the_day&action=edit

Since T315049, the behaviour has changed. The coordinates do not stick to the top anymore. It is now the same as shown in T310064#7987239.

They do slightly overlap the infobox when the Preview is scrolled all the way to to top (like shown in the description).