BFD how an administrative change differs from a failure
When a Bidirectional Forwarding Detection (BFD) session is administratively torn down, the protocol informs the BFD neighbor that an administrative change is taking place, and not a network failure. A BFD peering can be torn down by either removing the bfd interval command from the interface or by removing the neighbor fall-over bfd command from the routing configuration.
When either one of the above commands is removed, the following syslog messages appear on the BFD neighbor router:
*Oct 7 06:24:00.698: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:1 handle:1,is going Down Reason: RX ADMINDOWN
However, if an interface is shutdown, the following messages appear:
*Oct 7 06:29:50.303: %BFDFSM-6-BFD_SESS_DOWN: BFD-SYSLOG: BFD session ld:1 handle:1,is going Down Reason: ECHO FAILURE *Oct 7 06:29:50.309: %BFD-6-BFD_SESS_DESTROYED: BFD-SYSLOG: bfd_session_destroyed, ld:1 neigh proc:BGP, handle:1 act
Notice that the Down Reason in the first case is RX ADMINDOWN, while in the second, it is ECHO FAILURE.
From this info, we can conclude that when you disable BFD, the router informs the BFD neighbor that the action taken was an administrative action, and does not constitute a failure. When the interface is shutdown, that is detected as an echo failure, which is interpreted as a failure link, so the BGP session fails too.
Thus, BFD configurations can probably be safely removed without the fear of causing a failure or a disruption on a production network. Make sure you test this in a lab first though.