I have also encountered this problem and I was surprised how little detail is available on this.
Essentially my conclusion is that the .tab file uses MapExtreme libraries in order to process their info. This library is nearly perfectly accounted for in QGIS through ogr2ogr. However it is not perfect! As a result, sometimes in the saving process, if QGIS crashes, it will screw up the file.
I should preface this by saying that this issue is rare. It doesnt happen often and in general QGIS has little to no problems working with .tab files. However when this error occurs, it is one of the most frustrating and annoying issues.
Here are some things I have found which seem to help avoid this issue in the future:
Ensure your .tab has only 4 files. You should only have a .dat, .ID, .MAP and .TAB. If you have any other files associated, the chance of data corruption increases significantly. You can open your .tab file in QGIS or MapInfo and save as a copy. The new file should only have 4 files.
Only open the .tab file in one instance of QGIS. If you are working on a network where multiple people might want to look at the data in a .tab file, it is better to use .mif for just reading data. The .tab format can only accept read and write through one open instance. If you open it multiple times and multiple people try to save on top of each other, there is a chance that the data will be corrupted.
When there are unsaved changes in any open layer, do not give QGIS any heavy processing tasks. Basically, you are using QGIS 2 which is much more unstable than QGIS 3. Please switch to QGIS 3.4 when it is released. They are both completely backwards compatible (except for some plugins) and stability is greatly improved. If QGIS crashes when a layer is in edit mode, it can close the layer without saving the changes properly. This applies to all file types. However, due to the nature of .tab files, it can result in data corruption in the .MAP file. This causes some data to be completely dislocated in space or lost. There is no easy way to recover this data.
If file format is not a concern, there is a QGIS plugin which allows you to batch convert all open layers into another file type. I would advise using .gpkg or .shp. Both formats are way more stable. Also you can edit .gpkg natively in both MapInfo and QGIS.
Pack the .tab file. I am not sure how to do this within QGIS. Essentially .tab files store all the table entries. With large data sets, you may need to pack the table every so often to increase processing speed. It is really easy to write a MapBasic script which will pack as many files as you want at once.
As for any resolution on this data set. I have found that if this issue ever occurs, the orientation is still maintained. As a result, you can select all the data that has moved, then use the "move" tool and collectively move it back to a base point in another layer which has the correct coordinates and snap it. This will result in all the selected points moving and snapping back to the correct location.
If you dont have a base coordinate, then I am not sure what the solution is.