I hope this is the correct place to post about this; the TextMate GitHub repo doesn't seem to let anyone add issues. This setting:
defaults write com.macromates.TextMate.preview disableTabAutoClose -bool YES
...is being ignored by RC 29, 30 and 31 (if not earlier, I didn't try). The last "mainstream" release appears to be RC10, which works fine.
The setting is absolutely vital to me, so I'd really love to see this issue fixed. In the mean time I'll stick to RC10.
To be honest, I'm surprised it isn't the default. This is of course just a subjective opinion! For me, having tabs close and lose tab ordering and positioning is quite destructive to workflow, especially when working in projects with large numbers of files. I have to go scrolling up and down in the file browser trying to relocate something I'd opened for reference but has now closed again. The behaviour feels rather arbitrary / random too; the threshold depends on window dimensions, so it isn't very user-predictable. I never remember to right-click and choose "Sticky"; it's not something I've ever had to do in any other text editor or IDE, so it's just not in my muscle memory.
Has there been any consideration to using the current macOS system-wide tab bar instead? This "compresses" tabs when the tab bar gets full & automatically expands tabs towards the side of the tab bar most recently selected (at least in Finder or Safari, but maybe Apple implemented special subclasses and this isn't out-of-box Cocoa behaviour). If it's good enough for web browsers, where having very large numbers of tabs open is common, it's hopefully good enough for a text editor too. The "hide if overflowing" behaviour, if it were kept, could then become opt-in instead of opt-out. While other editors seem to be adopting Sublime's "temporary tab" approach, I've never been sure I like it; and going with the best-practice OS X core system approach has always felt like the TextMate ethos.