This is not a direct answer, nor is it necessarily 100% accurate as I'm not a functional language expert. But in either case, I'll share with you my experience...
About a year ago I was in a similar boat as you. I've done C++ and C# and all of my designs were always very heavy on OOP. I've heard about FP languages, read some info online, flipped through F# book but still couldn't really grasp how can an FP language replace OOP or be useful in general as most examples I've seen were just too simple.
For me the "breakthrough" came when I decided to learn python. I downloaded python, then went to project euler homepage and just started doing one problem after another. Python is not necessarily an FP language and you can certainly create classes in it, but compared to C++/Java/C#, it does have a lot more of FP constructs, so when I started playing with it, I made a conscious decision not to define a class unless I absolutely had to.
What I found interesting about Python was how easy and natural it was to take functions and "stitch" them to create more complex functions and in the end your problem was still solved by calling a single function.
You pointed out that when coding you should follow single responsibility principle and that is absolutely correct. But just because function is responsible for a single task, doesn't mean it can only do the absolute bare minimum. In FP, you still have abstraction levels. So your higher-level functions can still do "one" thing but they can delegate to lower level functions to implement finer details of how that "one" thing is achieved.
The key with FP however is that you do not have side-effects. As long as you treat the application as simple data transformation with defined set of inputs and set of outputs, you can write FP code that would accomplish what you need. Obviously not every application will fit nicely into this mold, but once you start doing it, you'll be surprised how many applications do fit. And this is where I think Python, F# or Scala shine because they give you FP constructs but when you do need to remember your state and "introduce side-effects" you can always fall back on true and tried OOP techniques.
Since then, I've written a whole bunch of python code as utilities and other helper scripts for internal work and some of them scaled out fairly far but by remembering basic SOLID principles, most of that code still came out very maintainable and flexible. Just like in OOP your interface is a class and you move classes around as you refactor and/or add functionality, in FP you do exactly same thing with functions.
Last week I started coding in Java and since then, almost on daily basis I get reminded that when in OOP, I have to implement interfaces by declaring classes with methods that override functions, in some cases I could achieve the same thing in Python using a simple lambda expression, for example, 20-30 lines of code that I wrote to scan a directory, would've been 1-2 lines in Python and no classes.
FP themselves are higher level languages. In Python (sorry, my only FP experience) I could put together list comprehension inside another list comprehension with lambdas and other stuff thrown in and the whole thing would only be 3-4 lines of code. In C++, I could absolutely accomplish the same thing, but because C++ is lower-level, I would have to write much more code than 3-4 lines and as the number of lines increases, my SRP training would kick in and I would start thinking about how to split up code into smaller pieces (i.e. more functions). But in the interests of maintainability and hiding implementation details, I would put all those functions into the same class and make them private. And there you have it... I just created a class whereas in python I would have written "return (.... lambda x:.. ....)"