I believe the crucial detail in this discussion is that network is unreliabe. There is no guarantee that data, sent over the network, actually gets delivered as it is. This means that network nodes (it depends on the network network, which nodes these are) have to do error recovery.
I will talk about the case that is relevant to TCP, that is data needs to be delivered as is, i.e., the same bits in the same order. [condition (1)]
Network errors can be bit errors (i.e., some bits change when arrived, 0 instead of 1, or 1 instead of 0) or chunk (think of it as packet at this point) errors (e.g., some chunk is missing, some chunks arrive more than once, chunks can arrive in different order).
First, in order to fix/detect bit errors we use two mechanisms - error-correcting codes and checksums. Error-correcting codes (layer 1) can correct certain number of errors. The idea is that checksum detects if errors are still present, and chunks for which checksum fails are discarded. That is, we are only concerned with chunk errors. As far as I know, the only meaningful way to recover from chunk errors (under condition (1)) are to retransmit the chunk.
So, this brings us to the answer to the first question. If you send one big packet (and the packet is really big) and some data in this packet was received incorrectly, you will need to retransmit the entire packet again. Depending on network technology the probability of each attempt to come incorrectly is pretty large. Thus it makes more sense to split data into chunks, send chunks more or less independently and then only retransmit chunks that were received incorrectly.
Side note: one of the fundamental design decisions of TCP/IP protocol suite is that nodes who do splitting (fragmentation) and reassembly of data should be the sender and the receiver, and not the nodes in between. You can read about in in classical paper "End-To-End Arguments in System Design" (link).
Now, let's go to the second question. To understand this we need to understand how layers interact, and what happens if one layer tries to send larger chunks than it is supported.
As we established digital data transmission sends data in chunks. At layer 2 these chunks are called frames. A layer 2 standard should define minimal and maximal size of the chunks. These sizes should depend on physical characteristics of the medium, but I am not that familiar with this topic to say something definitive. You could probably check classical examples of frame size for CSMA/CD Ethernet as an example.
What happens if the layer 3 has received a packet that is larger than layer 2 chunk. In IPv4, the current processing node (e.g., a router) should split the packet into smaller fragments and send these fragments. Next hop should reassemble the fragments into original larger packet. At this point IP does not do error recovery, i.e., if one of the fragments is not delivered, the whole packet is dropped. Experience has shown that this is very inefficient. Thus IPv6 removed hop-by-hop fragmentation. If this happens, the sender gets a feedback and should split packet and the receiver should reconstruct it.
Now, the main role of TCP is to do error recovery. That is the receiver detects what chunks are missing and notifies the sender, which in turn reconstructs the packet. Now, try to imagine how this could interact with IPv4 fragmentation. TCP splits data in chunks (called segments :)) of size X. Somewhere along the path these chunks can be split in smaller chunks of size Y ( Y < N ), then reconstructed back to size X, which can happen multiple times, and then the receiver needs to reconstruct received chunks of size X into original data. This means the more or less the same functionality must be repeated multiple times along the path. It is more efficient if TCP figures out the minimal Y, and splits data in segments of size Y. Then intermediate nodes do not need to do anything.
Note also, that the fact that IPv4 can do fragmentation would not change the fact that TCP still have to do its "fragmentation" as well, i.e., whether layer 3 does fragmentation or not would not change the required functionality TCP has to provide. On the other hand, for TCP it does not make a lot of difference if the size of the segment is X and Y. More info in the linked paper.
At this point I would like to make comments.
First, I disagree with the explanation of circuit switching. First, in 1960 I believe phone networks were analogue not digital. In 1980, digital phone networks (1) have frames at layer 2, which means that the issue of chunk size is relevant as well (2) are capable of doing time-division multiplexing, which means that several circuits can share the same path. Even before that, frequency-division multiplexing also allowed multiple transmissions to share the same physical path (e.g., radio/TV channels).
The difference between circuit switching and packet switching is the scale at which one can change multiplexing. If someone sends a lot of data, and is actively sending all the time, packet switching will not be better. Usually however it is not the case. For example, TCP sends user input, and user is doing nothing. In circuit switching resources would be reserved and cannot be used for anyone esle. In packet switching, each node can redistribute resources on "send time of one frame" time scale. The same idea would apply if TCP sender pauses sending because receiver cannot process packets (see flow control).
Second, phone network transmits real-time audio data. Transmitting real-time audio data is very different from TCP. In particular condition (1) does not apply. On one hand it is ok if audio chunks arrive not 100% correct, on the other hand error recovery in form of retransmitting chunks cannot be done (you can read more about restransmission problems here). The issue that I want to point out is following: in a primitive phone network, your phone will continuously transmit whatever your microphone recorded on regular intervals. Thus you will actually use all resources in the extablished circuit. In this case packet switching is actually worse then circuit switching. The reason, why is packet switching better, is because you have microphones that can actually detect if you are not saying anything, and not send anything in this case.