If you’re tracking testing, there isn’t much practical difference between keeping the previous stable repository enabled all the time, and enabling it as needed:
- downgrades are disabled by default, so a stable package won’t ever be an “upgrade” candidate from a testing package (in other words,
apt upgrade is safe);
- package installs might pick a package from stable, if the package doesn’t exist in testing; since you’re enabling stable in such cases anyway, the end result is the same, except that you might not notice before installation that a package is being installed from stable.
The real question then becomes whether it’s advisable to run a system with a mixture of packages from stable and testing. This is frowned upon (but mixing testing and unstable isn’t). In particular, you run the risk of installing a package from stable which has been removed from testing because it’s known to cause problems with the current state of testing; this sometimes happens, especially during major transitions, and is fixed by a newer version of the package from unstable. However, since you’re tracking testing, ideally you’re also paying attention to the development of the next release of Debian¹ (by following debian-devel, which isn’t very busy nowadays); such transitions are usually discussed there (sometimes not ahead of time, but soon after someone notices things going wrong).
Ultimately it’s up to you whether to install a package from stable when it’s missing from testing. If the package is still actively maintained, waiting for a few days will usually mean a fixed version becomes available. If it isn’t, or if it’s been removed, you need to figure out why it isn’t in testing and determine whether that has any bearing on the package that’s in stable. You can look at the package tracker to find the relevant information.
(I use a mixture of repositories, but I’m not a great example because I’m somewhat more familiar with Debian dependency issues than most.)
As far as plain-text HTTP v. TLS goes, the reason that Debian is configured by default to not use TLS is that it doesn’t add anything particularly valuable: package integrity is guaranteed by other means (out of band), and TLS doesn’t provide confidentiality when interacting with repositories (the size of each download is sufficient to determine what you’re downloading with a good level of accuracy). TLS has a non-negligible cost, both in terms of CPU on the mirrors, and because it limits the use of caches.
¹ This might seem unfair, but while stable releases really are supposed to be usable without paying attention to package installations and upgrades (i.e. Debian tries to live up to the expectation that its users can blindly trust its stable releases), testing is primarily where development of the next release happens, and its users are expected to pay more attention.
