There's more to experience when you log in!
There are always challenges when using WMTS or other tile-based services, which are at screen-based resolutions, for printing. I think the problem you're experiencing is due to MapInfo Pro not having a user-defined DPI setting. When you print, Pro realises it has a higher resolution/DPI space to fill and works out that the best way of managing this is to request a deeper level of tiles from the WMTS service. Unfortunately this is not always welcome. It can cause a tile stack to progress into a deeper zoom level serviced by a different map product, or often result in rasterised text being too small to read. If there was a DPI setting, the value could be lowered (still maintaining an acceptable print quality) and Pro could be restrained to hang on to the earlier zoom level (which may be the same as you see on screen).
There are some workarounds but they require some help from the service provider. For example, in our own web services, we provide "single product stacks" which only support one OS map product. Let's say that's OS 25K Raster. That will only be supported down to a certain level, but when you reach that hard stop, Pro has no choice but to hang on to that last zoom level and just stretch the pixels. This is sort of a forced DPI downgrade. To do this in OS Data Hub, you'll need to find a fudge that will stop Pro from accessing OS Data Hub's deeper zoom levels when printing.
Finally, it is a shame that the 660dpi versions of OS 25k and 50k raster products is not covered by the PSGA. There's a notable difference in print output quality.
Europa Technologies Ltd.
You can explicitly control the DPI in QGIS and this will determine the tile zoom that is used, so it's worth experimenting with that figure to see differences in output. I'd suggest something between screen resolutions (96/120dpi) and standard print (300dpi). I was tinkering around the 180dpi mark last time I wrestled with this and got some good results.
It would be really nice if MapInfo Pro has this setting since it would mitigate so many issues of printing from web services.
Perhaps unhelpfully, I'd say "all of the above"! While it would sometimes be useful to lock printed output to the currently viewing tile zoom level, sometimes it's OK to progress to the next one, or one after that. It usually depends on whether then next zoom levels are a higher resolution version of the same map content, or change to something the user doesn't want to progress to. This is common with zoom stacks which progress through mapping products of different scales. #3 and #4 are sort of the same, but while it's useful for some to play with DPI values, it's a little more involved than it should be. For some time now, users expect a WYSIWYG-type experience between on-screen and printed output. But, of course, that's not easy, so anything Pro can do to mitigate that hassle and simply produce the best printed output possible when using web services would be ideal.