FedRAMP's tediousness really depends on your organizations level of adherence to a well-governed, mature security, risk and compliance program. If you are a startup that's just been building stuff and selling it to customers, FedRamp can be quite an effort.
Like most external compliance, say PCI, HITRUST, FedRAMP, etc. It's all based on (some combination) if what are your current practices (documented and verified by a 3rd party), are the controls actually meeting our requirements, have these controls been tested (3rd party w/ documented minimum test cases), and when you put this all together, are you meeting our requirements. FedRamp, as do many others, have a continuous compliance requirement, so get used to working with 3rd party approved testers and auditors.
If your organization is relatively young, with a minimal perimeter and small in size, these probably isn't a very heavy lift. If your organization is older, with lots of people and diverse / redundant technology, this could be more complicated.
From a modern software perspective, the technology itself isn't the hard part. It's creating processes that are auditable and consistent, and making sure they are used. It can be a bit of a cultural shift and it can impact lots of people. The problem with modern software development is that there is this myth that engineers get what they want, or they go elsewhere. In my experience, people need to understand why they are being asked to change and that governance / compliance aren't dirty words, they lead to better, more secure products / companies. The one caveat is that if you have teams that only want to right functional code / service technical debt, and they don't care about where the company wants to go and why, this could be a problem.