I rarely notice the "stuttery and jumpy" movement Nightfrost mentioned, although a lot of people apparently do. I'm so used to playing 8bit and 16bit games that my brain has no problem interpreting pixel scaling.
Fraction dumping is subjectively valuable for "pixel-perfect" games due to how GM handles pixel size and position. Pixels will get stretched or shrunk during the scaling process, causing graphical defects some people find off-putting. If you remove the fractions and restrict yourself to certain screen resolutions, then you can get pixel-perfect upscaling. Then again, if you aren't scaling at perfect integers, then fraction dumping won't benefit your game at all.
Fraction dumping can greatly influence collisions if your game makes heavy use of fractions. Game Maker Studio uses round() on x and y, then calculates bounding box coordinates by adding the differences between the sprite's offsets and bounding box values as defined by the sprite properties. When the Draw event comes around, the coordinates are multiplied by the render scaling and then rounded. What this means is you effectively are moving half a pixel too early each time. At a low enough resolution, an x-coordinate of 111.60 is effectively the same as 112.50, which in turn can technically throw off collision detection. For example, if your hspd is 2/3, your collisions will technically be detected 1 frame early -- even though the hspd doesn't get rounded, an hspd greater than 0.5 for all intents and purposes may as well be 1.
Another reason for fraction dumping is to actually simulate 8bit and 16bit games. Something being in 8bits didn't restrict it to integer numbers from 0 to 255 (or -128 to 127), it could still have fractions, and most games on those systems did. Code efficiency was very important in the old days due to hardware limitations, and one of the easiest ways to streamline code was to drop the fractions whenever possible. Thus, instead of comparing full x coordinates, including the fractions, they'd compare just the integers, which also corresponded to what you'd see on the screen. Nowadays that's pretty much unnecessary, since modern systems can handle reals much more efficiently.