My question is why the HRMS db backup job is taking much longer time when compared with the FSCM backup job (i.e triple the time it takes)
Without any concrete performance data it's hard to say but I'll make an educated guess that it's due to the size of the final backup (in this case 254GB which is almost twice the backup size of the other database at 138 GB), so writing double the data to the disk is most likely taking up a good portion of the extra time... but again no performance data from the disks, cpu, memory to show this.
Here we have set to COMPRESS BACKUP for both the Database, but not sure why the HRMS DB backup file is larger when compared to FSCM db backup file size.
Compression results vary based on the type of data and the amount of entropy in the data, among other things. This is just telling you that the data in one database is apparently better for compression than another, so it has a better compression ratio. A quick example is that certain types of text usually compresses very well, but numeric digits may not as there may not be much uniformity to their layout. It also depends on the algorithm type, dictionary size, etc., which in this case you can't control.
There isn't really a whole lot you can do except figure out which item is the bottleneck in the setup (disk/memory/cpu/etc) and tune/get faster/better/etc. as 138GB in 40 mins = 58MB/sec and 254GB in 105 mins = 41 MB/sec which is very slow by most modern standards.