Actually this is not only a theoretical question. There were (are?) problems with BBR alghorithm which was too aggressive and was taking over streams with "classic" congestion mitigation mechanisms (like Cubic), apparently something like described here. AFAIR this was the reason for BBRv2 adjustments.
In such situation (abusive pacing) one stream takes over the entire bandwidth with some unfair ratio (depending on "aggaressiveness"), so other services run degraded, except for the abusive stream itself.
So if you ask for no flow+congestion avoidance at all: this will break every transmission (including own) on every link that gets overflown - after (during) jamming other streams it will inevitably make itself overflow too.
As noted by Ron Maupin in the comment below, this answer is about congestion, not flow control; however, since flow control handles entire end-to-end communication, while congestion considers the network capacity, it's obvious that flow control is irrelevant if the network (well, just include endpoints as parts of it) is not capable of delivering packets.
Thus the answer would be more complicated:
- if you only want to disable (make it ineffective in practice, anyhow) flow control, you could observe higher network utilization and packet drops, but no other effects - since the congestion avoidance might (like BBR) use the dropped packet metric to slow down sending, or much different issues depending on congestion control used by the sender; in particular, if sender doesn't use drop-resilient CC the stream would be unstable or even stall,
- if you meant disabling every stream speed control knobs (i.e. both, flow and congestion control) - the effects would be like described above, similar to UDP flood.
In short: disabled flow control (window big enough to be practically infinite) will cause excessive traffic and packet drops [but the transmission itself could be (depending on congestion control metrics used) intact; after all, every drop should be retransmitted, or expose direct effects of packet drops itself.]
As for the 2nd comment - yes, that distinction is crucial. Flow control being proactive (and declarative: "how much can(not) I take"), while congestion control retroactive (and using "hidden variables" like drop rate or RTT). In order to completely break the TCP one has to inactivate both of them, i.e. make the abusive change at least on sending side (aggressive/non congestion and ignoring flow control parameters by setting and keeping huge window); receiving party cannot exploit flow control to request unfair share of the bandwidth.
In a very simplified form one could say that while congestion control is about fairness, the flow control is about dropless. And to be honest ...both of them were failing on their job. Flow control cannot prevent random drops generated in dynamic environments (like wireless), while all the classic and even the modern CC algorithms didn't cope well in general sense "fairness".
One might even say that TCP is obsoleted and such statement is also truish. These (and many others) shortcomings were addressed in QUIC protocol which were implemented in web browsers to overcome long release cycles of dominating operating systems.
Fixing the TCP to catch up with modern world involved BBR - it is drop resilient and has fast convergence (dynamic, adaptiveness). And since v2 is not overwhelming against other streams and has it's own TCP pacing, so doesn't require FqCoDeL qdisc on L2 interface. This is how different elements of calculating stream desired speed are intertwining now.
As for the "extra complexity" of sliding window - in any asynchronous variable-length packet transmission protocol you need some kind of buffer management anyway. Building it in a way that can expose the available window space is some extra effort, but it's not like you could ditch this thing entirely.
Also, remember that TCP was designed decades ago and what you consider "some little overhead" currently was a really huge and unacceptable loss in times, where available bandwidths were orders of magnitude slower than today. Back then, without advanced congestion control, drop ratios beyond some threshold would lead to sudden stall of the stream, so not only the tiny bandwidth would be wasted on retransmissions, but also it couldn't be effectively used. Just think about 9600 baud fixed line with about 70% maximum utilization, when 3% drop rate nukes the transmission; if such line were noisy, the TCP would simply not work over it.