Nowadays? The protocols haven't changed, but you may mean that pipes are getting bigger while compute/storage aren't keeping up, so network admins are more likely to opt for sampling over raw/full.
If you want to see every connection you certainly can use netflow, just means you need to spec out your solution properly - and if you've got a lot of chatty traffic it may get expensive.
Obviously much less expensive than interface capture approaches like TFA - plus netflows will typically come from your routing infrastructure.
EDIT: Apologies, I had not really processed the implications of 'if you want to see every packet'. Yes, you're right, but netflow was never about seeing every packet, but tracking every flow (which IIRC is usually defined as src/dst addr+port + protocol) - which will include a running total of bytes/packets over time, so it's counting every packet, but certainly not inspecting every packet, at least not in a DPI sense.
Netflow will inspect every connection as it's established, and then track it until it's torn down. This is one of the reasons netflow, and especially sampled netflow, can report really skewed results against long-lived connections - think Citrix, f.e.
SFlow is the packet sampled version, Netflix/Ipfix will give you details on every flow. There was a period high speed devices (>10G) started dropping full sampling but it seems to have come back for even 100G devices. Limits around the total number of tracked flows still exist of course, you can't just flood a trillion tcp syns and on a 100G port and expect the switch to report on all of them. Theoretically you could do that with a pcap based solution but realistically it's the same problem the switch runs into.
Now if you actually care about per packet statistics rather than per flow statistics you'd want pcap. The more the world becomes encrypted the less interesting the actual packets become.
If you just want the general characterization of your data, then they are ok.