There are a few things to try or to consider. Firstly in your screenshot I see that you have the coordinate system as an attribute, but I don't see it in the information window (top right). So make sure that it is referenced there else FME won't be using it:
We also have to consider whether the coordinate system or coordinates are correct (or neither). As @buddiebubba says, you don't really know the coordinates are wrong. They could be correct but the coordinate system is wrongly tagged. Set the correct coordinate system and the data might drop into position.
But, if the coordinates are not what you are expecting (and you are discounting the fact the coordinate system is wrongly tagged), bad coordinates could be the source data is incorrect or FME has misread them.
To me, I think it's unlikely that FME is changing your coordinates, but you could open up the source data in its native environment (ie MapInfo) to be sure.
Alternatively... I can't tell if it's a MIF/MID dataset or TAB. If it's TAB, then FME has three different readers. Firstly try MapInfo TAB (MAPINFO) and MapInfo Tab (MITAB). Then there's also a format called MapInfo Extended TAB (a newer format), which you could try to see if it gives different results.
If all three give the same result then it's even less likely that FME is at fault, and more likely the problem is in the source data. If one is correct but another is a problem, then please let the FME support team know so any issue can be fixed (in the meantime you use the one that works).
If it's the data and simply a case of Lat/Long coordinates being the wrong way around, then you can use the CoordinateSwapper transformer in FME to switch the axes.
IIf it's a case of the sign being wrong on the data (eg you have +33.9 when it should be -33.9) then it's a little harder to fix. The simplest method I can think of is to extract the coordinates to an attribute (with a GeometryExtractor transformer) with a format like GeoJSON. Then use a StringReplacer transformer to place/remove - sign as necessary, and a GeometryReplacer to put that back onto the geometry:
As to how/why 136.059935 becomes 151.22157, I have no idea I'm afraid. Again, if all three FME readers are returning the same value, I'd return to the source data. If you don't have MapInfo to open the files, try using a hex editor to open the files and see if there is a header with the data extents. That at least would be some clue.