はじめに
Web Bluetoothで遊んでいてChrome OSでうまく動作しなかったのでcrbug.comの関連バグに書き込んだりしてたらFrançoisがハングアウトで色々と教えてくれた。日本語の情報もまだあまりないと思うので、せっかくだからメモとして共有します。
注意：あくまで個人の趣味で調べた情報です。間違った点、曖昧な点も含まれることをご了承ください。
chrome://flags/#enable-web-bluetooth
利用の際にはフラグをオンにする必要があります。このフラグを立てていると最初にブラウザを起動した際に、危険なフラグが有効になっている旨を伝えるメッセージが表示されるようになります。これは後述のChooser UIが実装されていない事に起因するものかと思われます。ウェブサイト上でボタンクリック等のユーザアクションを起こした際、一切の通知なしにBLEデバイスにアクセスが発生するリスクがありますので、その点を理解した上で利用してください。
requestDevice()
Chrome 47 (Beta)
このバージョンではnameとnamePrefixが使えないようです。services: [UUID]形式のフィルタでマッチさせる必要があります。この際の注意点ですが（もしかしたら、デバイス依存の話かもしれないのですが）Chrome OSレベルでデバイスをペアリングさせておく必要があります。シェルフのBluetoothメニューにBLEデバイスも列挙されているはずなので、事前にクリックしてペアリングした状態でAPIを呼ぶ必要があります。
2015/12/2 補足: konashi2.0.0がアドバタイズしているデータがサービスのUUIDを含んでいないのが理由でペアリングが必要となっています。konashi.jsからOTA Updateを使って2015/10/30に提供されたkonashi2.1.3-rc3にアップデートする事でサービスのUUIDがアドバタイズされるようです。
Chrome 48 (Dev)
nameとnamePrefixでマッチできるようになっています。name、namePrefixで探す場合に限ってはOSレベルでのペアリングは不要です。
OSレベルでのペアリングはリクエストが返してくるBluetoothDeviceオブジェクトにも影響しているようで、ペアリングしていればBluetoothDevice.uuidsにデバイスが提供しているサービスの配列が格納されます。ペアリングしていなければ配列は空。この違いもあってUUIDでのマッチングはペアリング必須になっている気がします。
2015/12/2 補足: この時点で返ってくるBluetoothDeviceオブジェクトが持つ情報は、アドバタイズされている情報に依存しているようです。
共通の問題
Chooser UIと呼ばれる、requestDevice()時に現れるデバイス選択UIが実装されていません。フィルタにかかるデバイスが唯一の時にはUIなしで該当デバイスの情報が帰ってきます。複数のデバイスがマッチする状況では試していません。セキュリティ的には穴がある状況ですが、色々と実験コードを書くにはむしろ好都合というか、テスト時の工程が減るので楽です。
Notifications
Chrome 48以降に限定ですがnotificationsが動作しているようです。AndroidではAPIは見えているけど動作はしない（イベントが一切通知されない）状況なので、この点に関してはChrome OSが一番実装が進んでいます。
まとめ
以上、簡単ですが利用の際における注意点のまとめでした。オフィシャルな情報はGitHub上にスペックと一緒にまとめられていますので、英語ですが参考になるかと思います。