Is there a way to reduce the amount of time spent on a point in time recovery?

Yes, you would have to restore the full backup, at maximum one diff backup, and all necessary log backups to perform a point-in-time recovery in SQL Server. In SQL Server, you cannot roll back already committed transactions to go back in time. You would likely want to use the STOPAT syntax to restore your database to the exact desired point in time.

In fact, because you are doing transaction log backups every 30 minutes, SQL Server is also clearing out the transaction log with each log backup--so to go back to an hour prior, SQL Server wouldn't even have the necessary information to roll back that far, even if SQL Server had such a feature (which it doesn't, sadly).

I can't answer whether it would take a "very long time" because restore time varies quite a bit based on how large the database is, how many changes are contained in the log / diff backups, and how many log backups need to be restored. For a small database that isn't very busy, the restore could be quite fast, but for a very busy multi-terabyte database, it could take a while.

Oracle has a feature called Flashback that will let you do what you describe, but SQL Server doesn't have an equivalent feature.

You could look into using the SQL Server snapshot feature depending on your use case. I use the feature prior to running production deployments and in non-Prod environments when I want to reset a DB to match specific test starting conditions. Since it utilizes sparse files, only copies modified pages to maintain the snapshot and allows you to maintain 1+ snapshots for specific points in time, they can be very effective, especially when tracking minute changes in a VLDB setting. One thing to be vigilant about is the amount of pages being modified as they will increase sparse file sizes accordingly and an outage may occur if you run out of space where the sparse files are situated.

Yes in short.

You will need to restore the last full backup, the latest differential backup and then all the log backups since the last differential backup.

This is the reason when a database grows too big, we usually ask the Dev team to purge the old data (older than retention period). Sometimes you do not have an option of purging and have to deal with it.

To be better prepared, always do an excercise of recovering the database in your Test environment, this will give you a rough estimate. Further to the estimate, an RTO can be agreed.