There is more information on SWMspeedruns.com, but in brief, SMW stores the player’s score as a 24-bit value as hexadecimal digits, and converts that value to decimal when it’s time to display it. There is no good way to do that that doesn’t involve figuring out the entire arithmetic, but Super Mario World does it particularly slowly: it starts with a copy of the score, then sees if it’s over 1,000,000. If it is, it increases the millions digit of the displayed score by 1, subtracts a million from the work value, then repeats. When it runs out of millions it repeats with the hundred-thousands, and repeats until it finishes with the tens. At least it doesn’t try it with the 1s, seeing as how nothing in the game awards single points!
In a worse-case scenario, with a score of 9,999,990, the code goes through this whole process every frame, consuming up to 8% of the time available for game logic.
What could the game have done to accomplish this better? It could have found out how many of each digit there was once instead of looping and incrementing. It could only figure out the score when the value changes. Or it could save the value as the digits themselves in decimal, just increment them by the right values when its needed, and then copy that figure to the screen. That’s largely what 8-bit games would do.
Even worse, if Luigi is the active character, the game does this twice: it figures out and prints Mario’s score, then it does it again for Luigi’s score, placing it onscreen in the same place.
While printing the score is just one thing the game does each frame, the effect is great enough that complex scores can lag the game, enough that speedrunners take the score into account to avoid it.
This adds to the evidence that Super Mario World development was rushed. It’s already known that a lot of the code in SMW is buggy, allowing for some truly heroic exploits like programming a text editor in SRAM purely by manipulating objects in an early level.