Quick and dirty answer: It's totally incorrect to use classic bluetooth in this way at all. The answers to your connection strategies are irrelevant because using BLE would result in between a 10-20 fold power reduction for both host and device. So stop worrying about classic bluetooth connections and use BLE. That is correct answer.
Long, in depth answer including general overview of Bluetooth varieties and Bluetooth 2.1 power "saving":
It is important to understand the somewhat confusing topology of the bluetooth standard itself.
Bluetooth 4.0 is an umbrella specification that contains 3 completely different technologies. It is not an extension of earlier bluetooth versions, but rather a way to force devices to support multiple but totally unrelated wireless technologies at the same time if they want to be able to say they comply with BT 4.0.
Bluetooth 4.0 is, at the minimum, just the low energy protocol. In this instance, it called BLE or Bluetooth Low Energy. It has zero compatibility with any bluetooth device except for other BLE devices. This is because BLE is completely unrelated to other incarnations of bluetooth, and doesn't even use the same radio. It's a totally different technology, stack, protocol, RF solution, everything. The only thing it shares with other versions of bluetooth is the name.
The second technology contained in the BT 4.0 specification is Classic Bluetooth. This is just, well, classic legacy bluetooth. BT 2.1+EDR. If a device additionally supports this, then it can label itself as Bluetooth 4.0, since this implies that it is backwards compatible with earlier bluetooth devices, which it is. But not so much 'backwards' compatible. These so-called dual mode bluetooth devices have two stacks, two radios, though usually integrated on a single chip, one BLE radio and one legacy Bluetooth 2.1 radio. So most BT 4.0 devices are no different than 2.1 devices. Essentially, bluetooth proved to be kind of a crappy way to do stuff if you wanted low power, so we started from scratch and developed BLE.
Finally, if a device is labeled Bluetooth 4.0+HS, then it also supports bluetooth highspeed, which is just Wifi. Yes, you heard me right. It means it has an 802.11 radio in it, the only difference is bluetooth is used for the negotiation/connecting phase, so it's effectively just ad-hoc Wifi with bluetooth acting as a convenient method of automating the connection process. In phones that support this, usually the already-present wifi radio will be used for this, and BT4.0 HS is designed with this in mind, it generally will not have a dedicated 802.11 radio just for it. It's not special enough.
With that cleared up, you state you are using 'regular bt', or more correctly, Classic Bluetooth.
The Apple document you linked is irrelevant to you, as that documentation is all specific to Bluetooth Low Energy. It's part of apple's Core Bluetooth API, which is a Bluetooth Low Energy abstraction layer. Nothing in that section, nor the entire Core Bluetooth developer documentation, has anything to do with Classic Bluetooth, and Classic Bluetooth doesn't even work the same way as BLE. If you've been reading any of that under the assumption it had anything to do with the unrelated technology you're using, which unfortunately also is named Bluetooth, then you'll have a very flawed and incorrect idea of what is going on. It's already given you a totally incorrect idea on how Classic Bluetooth connections work, which I think is the source of a lot of your confusion.
So to be clear, that linked document is talking about a completely different and unrelated technology than what you're using. So those best practices have nothing to do with what you're doing, because you're using Classic Bluetooth.
The second link, referring to a BT device still drawing power, is about Classic Bluetooth and is relevant to your situation. It is NOT true for BLE, but for definitely true for Classic Bluetooth.
Yes, the radio consumes power whether anything is connected or not, and yes, that is pretty crappy. That's why we ditched that technology and started over from scratch when making BLE.
You then again link to an article about having low level access, but this is for a BLE chip. This article is, again, completely irrelevant and there is no 'low level access' that you're not getting. You're using Classic Bluetooth, it does not have any of those features and could not because it doesn't work like that nordic chip.
It really sounds like you're hugely and haphazardly conflating Classic Bluetooth and BLE (to no fault of your own, I blame the naming decisions of these technologies entirely for the confusion it causes people begin working with things named bluetooth), so I am not quite sure how to even properly address your question.
But here is my best shot. Let's start by giving you a correct understanding how how Classic Bluetooth connections work.
There several different phases:
Inquiry is what more familiarly known as discovery. It's very costly for both the host and the devices, which is why it tends to be a special mode where you make devices 'discoverable' or 'pairable'. It's that annoying thing we always have to do when we get a new bluetooth keyboard or the first time we get our phone to talk to our car stereo. The bluetooth host shouts on all its channels as loud as it can to get a roll call, and receives and saves specifics about each device. These specifics are, ahem, specifically the information needed to actually connected to them. So the inquiry phase isn't even the actual connection part. This is the host asking a device out on a date, but not the date itself.
Paging This is what is generally meant by connecting. This is going on the date. This, for example, is what happens when you manually click connect on a list of already known bluetooth devices on your phone/laptop/whatever. In this case, the bluetooth host attempts to connect to a device that it already knows everything it needs to know to do so (previously gathered by inquiry). This is also very costly power-wise for both the host and device. Additionally, this is a one way thing. A host can initiate a connection to a slave, but a slave that isn't connected can't connect automatically unless it is been bonded. When bonded, the host will periodically see if the device will respond, and if it does, it connects. However, again, this is still the host initiating the connection. And why the radio continuously draws power - because its constantly saying, "hey guys, anyone there?".
Once connected, this is not as big a deal as one might think. There is an active mode, which is the highest power, sending-and-receiving data mode, and there is also something called sniff mode, where the slave will mostly power down it's radio and only wake up periodically and briefly to let the host it's still there and to check if the host wants to talk to it (in which case it will upgrade to an active connection). Otherwise, it goes back t sleep until the next interval. This is what an active connection will revert to once it goes idle (no data being transmitted). This is usually automatic, and the cause of the potential maximum 100ms latency of Classic Bluetooth.
There are also a couple of other specific low power modes, but these must be issued by the master to a slave. It can command the slave device to hold, which means to sleep/power down its radio for a set amount of time, then wake back up. This is a one shot event.
A master can also park a device, which is effectively disconnecting it. The device will power down it's radio to a minimum state where it will do nothing and transmit nothing and only listen, barely. What it listens for is a signal from the master to wake up again.
It's important to see that all of these are controlled by the master/host. And even more importantly, these effect the power of the device/slave, not the host/master.
In Classic Bluetooth, you're always going to be consuming power and connecting and disconnecting from something will require more data and consume more power especially if you're just periodically sending some data. If you don't have access to any of these modes in software, then its likely that they are done automatically for you, but definitely do not connect and disconnect over and over. Connect once. The main additional power cost is determined by how much data is actually exchanged, and the handshaking and what not that goes on doing a full, cold-start connection to something is going to take a very, very long time in sniff mode for it to make sense to disconnect it (and thus need to reconnect again) if you don't need to.
Finally, in closing, Classic Bluetooth is meant as a wire replacement. It's meant to connect then stay that way, and always be there to exchange information. Which is why it sucks for battery life.
So if your application doesn't need what is essentially a constant, wired connection (only without the physical wires), then you should not be using Classic Bluetooth. If your device only needs to send data sporadically, and more importantly, without being polled by a master or host (it should be able to speak up rather than wait to be asked) then you should be using BLE. Your idea of connecting, sending data, then disconnecting is how BLE is designed to work and it is probably a BLE document that gave you that idea. This is not how classic bluetooth is designed to work, and most certainly not how you should use it.
So I guess the short answer to your question is that Classic Bluetooth is the wrong technology and you should not be using it at all. And you will not improve battery life by fooling around with connecting and disconnecting. The only way you're going to gain a meaningful improvement is by using the correct technology for your application, which is BLE.
As for battery life improvement, it will be on the order of...well..a magnitude. 10. Or probably more if you do it right. BLE is pretty great. BLE is what you use, the only time you don't is because you have no choice (you need to stream audio for example).
