TL;DR
Yes, there where several professional mainframe (related/connected) devices that did use analogue recording. Most of them developed arround 1970 and used until the early 80s.
The key reason to use them was cost reduction in a large volume installation and higher reliability. Where ever the low transfer speed and the serial nature of tapes was acceptable, an audio tape solution could produce resonable cost cuting. The perfect seting is where (much like in the OPs example from the SU) remote stations connected over low speed lines, often operating only temporary (dial line) in accounting/banking/retail, where data processing was serial anyway.
(Caution, Granpa ist telling wartime stories again)
Prelude:
To simplify the description how the development went, lets assume a large nation wide bank with branches in many cities and multiple offices in each. The same principle of course work well with retail business, insurance companies etc ... coincidentally exactly the businesses that adapted mainframes, and electronic IT in general, first.
In each of these application are based around the fact that information is created local and needs to be balanced/processed into a unified data base. In case of banking the most used process would be arround account changes (deposit / transfer / withdrawl), a process where the traditional name, 'posting transaction' already hints its nature in communication. Before anything that reasembles modern IT came, there all these transaktions where already quite thruout formalized, but still kept as local as possible. If one wants to access his account, a visit at his local branch was the only way. Remote access was a lengthy and slow (days to weeks) process, where in fact withdrawl and personal transport of cash between banks often was less cumbersome. Ledgers where kept local and centralized ledgers where only used for transfer accounts of rather large / important customers.
Punchline
With the advent of automated data processing in form of punch cards, not only book keeping within one office got simplified, but also centralized bookkeeping (for all branches in a city, state or nationwide) became possible. Daily data was collected in machine readable form in each branch office and transfered to a central processing department, run against accounts (and whatsoever), finalized, and return data was sent back to each office.
Early remote data entry relied on punching cards and transporting these daily to the processing center. Information was sent back as printouts to each branch office.
To have actual data each day, the whole processing cycle (gathering punch input, processing and deliver output) had to be done in a single night, so transport time was restricted to a few hours (~3-4) one-way. Thus the size of a region where over night processing in a central location could work was restricted to physical travel time equalling the size of a large city region or a small state. Anything beyond couldn't be 'up to date' (another term coined here - AFAIK) and was done in a incremental stages with less actual data on each stage.
E.T. Phone Home
First step in further automatization here was to add remote card readers. Originally this was ment to enable better centralization, ad data transfer across a country could be made in a matter of seconds per records. First installed at the 'local' (city/county) processing center and sending into a state/national center, they became soon rolled out to each branch office. They still punched all their posted transactions on cards, but instead of having someone drive them to a processing center, the cards were now put into a locally installed card reader, and everyone went home. At some point during the night the mainframe called into each branch, activated the reader and processed the batch much as if on a local reader. In fact, from a mainframe program's point of view it was like local, even on assembly instruction level. Seamless device integration was always a core issue in this world.
Such handling was called a Remote Job Entry (RJE) or Remote Spool Entry (RSE) while IBM called its hardware Remote Batch Terminals.
The return path was at first still delivery of paper via a van, but soon also local printers got installed. Again, after processing the Mainframe dialled the branch, activated the printer and had it running. The real high quality and unbelievable prices of mainframe printers (as with remote entry stations) also originated in the need of having them operating at night unsupervised without paper jamming or alike failures.
(And yes, you read right, data connection was dial out, not dial in. It's like token ring vs. ethernet. More efficient and secure vs. brute force. I still remember a chat with an old time mainframe operator who couldn't understand why, heaven help, a mainframe should be able to acept dial in connection, and why mainframe modems should even be able to do so. God, well, IBM has created leased line connections for mainframe to mainframe and dial out for mainframe to branch office. Everything else would just lead to chaos, anarchy and the end of civilisation. That chat happened around 1980. You see, mainframe mindset is really a bit different form what minis, micros and most of today's IT runs on)
The reason to install such hardware in each branch wasn't as much cost saving at first, but enabling of business at all.
Cheaper, More Relliable and faster
As said, paper jam with punch cards and printers where a relevant issue in early remote stations running unsupervised at night. So solutions to either scrap this at all, or at least delay the paper pased process into office hours where much sought after. Using Memory was out of scope, as the amount of data for a single branch office with several dozend KiB inbound and maybe even over 100 KiB outbound did easy exceed any reasonable amout of storage. Keep in Mind, in the late 60s, 16 to 64 KiB was a reasonable sized mainframe memory. Puting racks with 128KiB or more in brach offices would be prohibitive expensive and in no relation to replace the paper it would replace.
For larger branches, or intermediate date collection centers usage of remote operated mainframe tape drives was used, but that was more of a handling improvement during data transfer as they where staffed in the night anyway.
There where many atempts in the 60s to improve this situation with somewhat cheaper (easy, as IBMs prices did leave room to improve on) and more reliable (not easy) machinery, and new concepts. Most promesing where paper tapes. They did combine the ease of an automated endless media (so way less paper jam) and beeing cheap enough to use it for intermediate storage of printouts. So reading (toward the mainframe) was more reliable, while writing could go at night to a paper tape punch and later, during office hours, feed to a supervised printer. Such a tape punch was way cheaper than a card punch and using less expensive material at the same time. Still bad handling could screw it big time.
Development in this area was mainly driven by smaller plug compatible manufacturers, thanks to standardized mainframe interfaces and protocols. To the mainframe such stations did present themself as 'standard' Remote Batch.
One key issue in all of this is data transmission rate. First connection where literally TTY based, so 33 bit/s of data (50 bps brutto). Around 1970 standard for mainframe dial out was 1200 bps, in the end of the 1970 2400bps was considered state of the art. 1200 bps or even 2400 bps is still within the capabilities of paper tape and more so punch cards (when calculating here keep in mind that they just need to record netto data, while transmission lines have to include various kinds of framing).
Papertape sill had the drawback of being a one time media and its inherent ways of screwing it up. Audio tape could fill exactly the need here, as it was reliable enough, machinery was (rather) cheap and data rate did fit. But it still suffered from complex handling and errors originated here. This changed when Philips introduced the compact cassette in 1963 (?). A nice system not fault prone due direct handling of the loose tape.
(Now there where next to no handling errors left beside loading an empty cassette - which ofc happened and ofc it was almost never the clerks fault but the machine was broken and service got called. Been there, done that. More later).
Soon several companies including names like Olivetti, NCR, Nixdorf, Bull, Honywell or GE developed remote batch entry stations where data was typed direct (only memory for line or record editing needed) onto cassette, which later at night was read as batch from the mainframe via dial out. Return data (if needed) was stored in a (later) second session again as batch on (another) cassette. Cheap standardized cassette mechanics made it possible to have severaldrives and reliable operation. Ofc, cheap here has to be seen in relation to mainframe tape drives. These mechanics wheren't from consumer grade manufacturers as with early home computer drives, but special build and much more controllable. A drive unit (no electronics) from NCR was still rated above 1000 Mark, while a complete consumer recorder was available for 40 or less. The advantage of cassette drives for professional equippment where due standardisation and available knowledge - and ofc, as said the higher reliability due reduced user interaction (PEBKAC principle)
As Time Goes By
During the 1970s an overwhelming number of decentralized data entry points where based on compact cassette system - while at the same time larger branch offices became 'intelligent' data entry system, read, minicomputers with local disk storage. During the second half of the 70s into the 80s all cassette based entry stations became replaced by small computer systems still working with the same entry and connectivity priciples but using floppies.
After that, I can't recall any use of audio level recording for mainframes. Also remote batch got more and more replaced by online batch where data was collected direct on the mainframe using 24/7 online connection. Nonetheless, processing is still today often done in nightly batches. Batch will never die
(Last story here: Now, PEBKAC errors are not realy restricted to tapes or punch cards. Floppies offered a whole new range of posibilities. I remember a story from a small bank branch office in a tiny village near Rosenheim, itself a small city about 60 km east of Munich (the area is worth a vacation). At one point they did call for service almost every other day, because the nightly transfer has failed. Located in the late 70s, the data entry was rather modern, using a closed system, 8080 based, with screen edit of entry record, even able to handle multi card records and showin meaningfull entry masks. Data created was stored on a floppy drive and transmited as nightly batch. They swear that they entered the data and the system did acknowledge everything as correct when entering, but the nightly transfer failed over and over, always claiming that no data could be read. This did go on for several weeks. At that time it was already an issue at CEO level between the bank and our company. So every phone call might have cost more than a new entry station. Anyway, we couldn't find any error at all. We could prove and demonstarte that the station was working as intended. They reserved even a whole mainframe for several hours to replicate the nightly situation. More than 30 people where needed for setup. All worked fine. Tensions (at management) did grow further. They where close to cancel some real large (>10m Mark) orders.
At one of these days, by sheer accident the bank clerk did forget to remove his work disk when service once more tried to locate the problem. It might be neccersarry to add here thet they where strict order to never let any of us touch customer data - as well as we where forbidden to do so. No problem as posted transactions where the only data in question and all was stored on a single 8" floppy. Now that day one of us removed the customer disk and by chance did notice that he could lierally see thru the disk. The magnetic layer was almost completly removed.
Long story short, they put heavy use on the same tracks of a few disks (less than a pack) for several years, each and every day, until the disks where complete worn up. No need to say that some side suddenly got rather calm. Three lessons to remember: Always check the whole production process; never trust a customers knowledge and most important Floppy drives are cutting machinery)
