解釈が正しくないですね。
正確には、前提条件として「動かない」が、例外として「動く場合もある」というのが正しい解です。
マイクロソフトでは、Windows 7でのVB5.0アプリケーションについて一切の動作を保証していません。
また、VB6.0についても、APIは大方実装されていますが、動作の保証を行っていません。
即ち、VB5.0は動けばもうけもの。VB6.0は一応動く仕組みはあるが、動かない場合があっても、何らかの対処方法を説明することはないというスタンスです。ただし、VB6ベースのコードは、.最新のVBでコードのアップグレードを行なえば、ある程度は自動で最新コードへの最適化が可能です。（ここで最適化が行えない部分に、Windows7 64bit環境で実行に沿わないものが含まれます）
そのため、１に関しては、制約も何もなく、動かない前提で動かすべきということになります。
VB6ベースの場合は、動く前提ではあるが、特定のカーネルドライバを直接キックしたり、自ら設計した独自のAPIを利用する場合は、動作しません。尚、16bitベースのコードは64bitOSでは全面的に（全て）動作しません。
２について、Windows On Windows 64(Bit)は、VB6.0より後に提供されるWin32の共通参照関数群（DLL、OCX）のAPIを、64bitの代替APIに割り当てて実行できます。具体的に言えば、AというAPIがあったとしたら、そのAというAPIと同じ役割を持つ64bitAPIに処理を引き継がせ、処理を実行します。また、独自APIであってもハードウェアに依存しない程度で、ユーザーモードの範囲内で計算などを行うなら引継ぎなしに実行が可能です。
しかし、先に記載したように、Windows 64bitが保持しているライブラリに存在しない外部APIを利用している場合、既に64Bitでは廃止された16bitAPIを利用する場合、カーネルモードで直接ハードウェアをコールすような素行の悪いプログラムやライブラリ、脆弱性やパフォーマンスの問題などによって引継ぎが出来なかったAPIを利用する場合は全て動作対象外となります。
尚、これはVB5におけるルールではなく、VB6より後のバージョンにおける条件です。尚、例外に関するルールが明確に開示されているわけではないので、抽象的な回答であることはご了承ください。
ということです。
個人的な回答をすると、基本的にVB6以前のコードは、設計されたソースがあるなら、最新のVisual Studioにてコードをアップグレード（機械最適化）してみることをお奨めします。それで、適正ではないと判断された箇所については、手作業で最新VBベースソースに修正するのがベストです。
全体的にNGになる場合は、今後も踏まえ設計からやり直した方が良いと思われます。
あなたの思ったこと、知っていることをここにコメントしてみましょう。