The Atari TT was based on the earlier ST line of computers but with a 32 MHz 68030 instead of an 8 or 16 MHz 68000. There were a number of extensions made (e.g. new video modes) and the memory architecture had some differences as well. Though largely backwards-compatible, some earlier software reportedly would not run on it. What specifically caused some ST software to fail to run on the TT?
Beyond the usual TOS compatibility issues which affected all Atari STs, the TT add the following twists:
- its faster CPU meant that some programs (games) ran too fast; this wasn’t as much of a problem as on the PC since most games used the vertical blank interrupt for timing;
- its 32-bit address bus meant that programs which used the top eight bits of addresses suddenly stopped working, as detailed in Brian H’s answer (the unofficial
24bit.prg, available here, will program the MMU so those bits are ignored, so that games such as Ultima III will work);
- it dropped the blitter, emulating it in software instead (which turned out to be faster, using the 32MHz CPU, than the 8MHz blitter anyway); programs which address the blitter directly instead of using the TOS routines fail to work (so some STE-specific games won’t work);
- its list of supported resolutions doesn’t quite match the ST’s, which affects some programs.
The Atari wiki has a list of TT-compatible games which gives a good idea of what to expect. This Atari forum thread also contains a lot of useful information for people trying to run games on the TT (it gives the impression that lots of games need patches, but many of those patches aren’t required, they allow the games to run from the TT’s hard drive).
The question is sort of broad, since there are many ways to write software that targets the specifics of ST hardware, and which leads to programmer assumptions that break when the hardware changes even slightly. That said, you identified one of the main issues for games: the faster CPU. Not being able to slow the CPU down to the expected speed of the ST would be an issue for any games that relied on precise instruction execution speed.
Another likely culprit, which also affected lots of Amiga and Macintosh software in the transition from 68000 to 68020/030, was the programmer "abuse" of using the upper 8-bits of addresses to store additional data. Addresses on the 68000 are 32-bit, just like with the 020/030. But the 68000's address bus is only 24-bits (16M maximum memory). So it was very common for programmers to conserve some memory space by using the upper 8-bits of address data for purposes other than addressing memory. On the 68000, the extra bits were ignored by the hardware, but not so on the 020/030. This led to many unexpected crashes on the 32-bit machines, especially since the OS for these machines didn't include memory protection from user applications. On the Macintosh, the early system software had used this means of conserving memory, and that was one of the contributors to the lengthy push to get "32-bit clean" ROMs for 32-bit Macintoshes so that they could actually support >8M of RAM.