試してみたところ、こちらでも表示させづらいと思いました。
表示するためには、マウスを素早く動かして TextBox 内に移動するか、TextBox 上でマウスカーソルをいったん停止してから少し動かし、再び停止する必要があるようです。
# こちらの環境は、Windows XP(SP2)、.NET Framework 2.0(SP1) です。
そこで原因を調べてみたところ、以下のことがわかりました。
ただし、それに対処するための良さそうな回避策は思いつきませんでした。
一応、TextBox の BorderStyle を BorderStyle.FixedSingle にすると、ツールチップの表示は正常になります。
まずツールチップの仕組みですが、ツールチップは Windows クラス "tooltips_class32" の仕組みを利用して表示されます。この仕組みでは、ウィンドウメッセージ TTM_WINDOWFROMPOINT を処理し、このメッセージで渡されるマウス座標を使ってツールチップを表示するコントロールを決定します。
このメッセージは、本来はツールチップが表示される直前に発生するため、渡される座標は停止しているマウスカーソルの座標になりますが、ビジュアルスタイルが有効な場合にはマウスを動かしている最中にも発生するようになり、その上、渡される座標は移動中の座標になってしまいます。確認したところ、この座標はマウスを素早く動かさない限り、TextBox の端になっていました。
そして、そこへもう一つの仕様が影響します。
BorderStyle が BorderStyle.Fixed3D の場合には、TextBox のクライアント領域は少し小さくなります（BorderStyle.FixedSingle では小さくなりません）。これが影響することで、座標が TextBox の端の場合には、現在の .NET Framework でのコントロールを決定するロジック（最終的には以下のコードのようなもの）ではコントロールの取得に失敗します。
この失敗のために１度目の移動ではツールチップが表示されませんが、２度目の移動ではすでに完全にクライアント領域内であるため、処理が期待通りに実行されます。
この２つの動作が影響することで、TextBox では、ツールチップを表示させづらくなってしまっていました。
Windows 側の問題のような気もしますし、.NET Framework 側の配慮不足のような気もしています。
ツールチップ表示対象コントロールの取得ロジックのイメージ
Windows API の定義（以下では WinAPI クラスとして定義）は省略しています。
// TTM_WINDOWFROMPOINT で渡される座標が TextBox の端
Point cursorPosition = this.PointToScreen(textBox1.Location);
IntPtr hParent = textBox1.Handle; // 親として TextBox のハンドル
WinAPI.POINT p = cursorPosition;
WinAPI.MapWindowPoints(IntPtr.Zero, hParent, ref p, 1);
// http://msdn.microsoft.com/ja-jp/library/cc410658.aspx を見ると、
// 親のハンドル（この場合は TextBox）が返されて良さそうにも思いますが…
IntPtr hChild = WinAPI.ChildWindowFromPointEx(
hParent, new Point(p.X, p.Y),
(uint)WinAPI.ChildWindowFromPointFlags.CWP_SKIPINVISIBLE);
MessageBox.Show(hChild != IntPtr.Zero ? "○取得成功" : "×取得失敗");
遅レスでしかも説明ばかり長々となり、肝心の回避策が提示できませんでしたが、何かの参考になればと思います。
# tooltips_class32 の仕組みは、にわか勉強です。
