Chrome Version: 57.0.2982.0 Canary
OS: Mac OS X 10.10.2

Try the example at https://googlechrome.github.io/samples/web-bluetooth/device-disconnect.html. After you have connected to a device, press disconnect, wait for 3 minutes and then press reconnect.

Output:
Requesting Bluetooth Device...
Connecting to Bluetooth Device...
> Bluetooth Device connected
> Bluetooth Device disconnected
Connecting to Bluetooth Device...
Argh! NetworkError: Bluetooth Device is no longer in range.

The device is certainly in range but since the browser has not made a scan during the last 3 minutes the device is removed from the cache and therefore refuses to connect.

We can't have it that way. A pretty common thing that happens if you want to have a long-lived connection is that the connection eventually gets lost due to for example radio interference (disconnected due to supervision timeout) and you immediately need to reconnect to re-establish the link by calling device.gatt.connect().

An example that also seem to crash Chrome's bluetooth is to first scan. Before connecting, stop advertising on the peripheral. Then call device.gatt.connect() and wait 3 minutes. Then start advertising.
These steps can be done from https://googlechrome.github.io/samples/web-bluetooth/device-disconnect.html as well; simply stop advertising on the peripheral as soon as the device has popped up in the device selector UI, before you connect.
What's happening then is that the bluetooth system stops working in that tab. Requesting a new device does not put up any UI and all other gatt commands do nothing, promises neither resolve nor reject etc.

The standard mentions nothing about timeouts and it even explicitly states for the connect() method: "Note: These procedures can wait forever if a connectable advertisement isn’t received.".

Cause seems to be related to this function: https://chromium.googlesource.com/chromium/src/+/15b1f5307b13a30002693aa1907819c447db4954/device/bluetooth/bluetooth_adapter.cc#375