Your best bet is to not "defragment" SSD storage.
Eventually, SSD will lose capacity slowly and gracefully as the controller can’t write the data correctly to exhausted cells, but the repair data from 2011 through 2018 shows that Apple SSD are orders of magnitude more reliable and have longer life than HDD storage currently or in the past could achieve.
The life span of the drive is a function of how the controller decides to write data and how much of the capacity is held in reserve to hide small errors over time. An SSD in general will wear out due to write exhaustion before a hard drive will as the magnetic media can withstand several orders of magnitude more writes than SSD memory cells. So the life span is basically set, and defragmentation means more writes than are needed and may in practice increase the chance your storage will degrade before something else causes you to stop using it, Granted, most people are not going to wear out their SSD - especially when you consider the warranties for OEM parts are often longer than one year / three years in the case of AppleCare - but reducing things that can cause thousands (or millions) of unnecessary erase and re-write operations is prudent advice.
But it gets worse for defragmentation than simply adding wear to the memory.
Since an SSD has no moving parts, retrieving a block of data has no penalty due to one block being stored on one chip versus another. The distance electrically to all the data is basically a constant. This is not true for a traditional magnetic drive with spinning platters and a movable read head.
On a spinning drive, the distance between two blocks is affected by head armature movement, rotational timing and cache status. Retrieval time is not at all constant, so "fragmentation" has a performance impact on traditional hard drives due to the mechanical nature of the storage.
Furthermore, SSD controllers selectively manage storage so defragmentation is not only unlikely to speed things up, might actually act counter to the normal storage prediction algorithms, and slow down access since the controller decides where to store data using the extra overhead. Since the device cannot erase just a block of storage, when you "delete" something on SSD, it often is just marked free and will not get actually erased until all of the data next to it is marked as free or the drive runs low on space and triggers a clean up on it's own.
Letting the SSD manage it's fragmentation works better than trying to have the OS micromanage storage that doesn't match traditional hard drive storage mechanics.
OS X creates the recovery partition as an alternate boot solution for ease of reinstallation and troubleshooting.
It is not needed for normal operation, and as someone that's familiar with boot technology and options, the simplest option would be to simply delete the partition entirely and patch the partition table if needed.
Here is a stock layout:
Mac:~ me$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *251.0 GB disk0
1: EFI EFI 209.7 MB disk0s1
2: Apple_HFS Macintosh HD 250.1 GB disk0s2
3: Apple_Boot Recovery HD 650.0 MB disk0s3
You could merge partitions disk0s3 into the partition that precedes it (in this case) to effectively erase and then delete the Apple_Boot partition listed as Recovery HD. In this case, you would need to be booted to some other drive than disk0 to have both disk0s2 and disk0s3 unmountable (which would make them disk1 or higher in all likelihood).
diskutil mergePartitions JHFS+ "Macintosh HD" disk0s2 disk0s3
Should that not work, you might have to image Macintosh HD to another drive as an img file (or straight partition to partition) and then repartition hdisk0 to have just one partition and restore.
As to the deeper question, my guess is that the "hiding" of the partition isn't compatible with other non Apple tools and is confusing the issue - hence the advice to just remove it and count on alternate options to restore your system or boot externally in stead of the recovery HD.
Best Answer
As long as you're not using FileVault it won't be a big problem. If you are using FileVault or encrypted drives in Mountain Lion then Tiger won't be able to read them but even then it won't cause damage as long as you don't erase them when Tiger complains that they are unreadable.
Spotlight works differently in Mountain Lion so Tiger's spotlight and Mountain Lion's Spotlight will each have to reindex all your drives when you switch back and forth but that just takes time, it's not permanently damaging.
The riskiest part is trying to create a dual-boot disk.