Both teams are doing the same thing
Team A used ssh-keygen, to create a private/public key pair,
which stored the private part on
$HOME/.ssh/id_rsa, and added the public key to the authorized_keys file on the server. Then when sshing to the server, it will by default read the private key from there, thus accessing the server without having to enter any password.
Team B named the file differently (they probably used the
-f parameter), and is using
-i every time, as otherwise ssh wouldn't find it.¹
In every case, ssh needs the private key file (either it accesses the private file directly, or the key is already loaded in a ssh-agent), only the place where it is located differs. There are a few other key filenames it tries by default if they exist, and you could specify a different location on
~/.ssh/config (even different keys for each host if you wanted!), so you don't need to explicitly enter the key filename on each run.
(In both cases, the key could be protected with a passphrase, but none of the teams seem to be doing that)
So, to answer your questions:
What is benefit of using .Pem file?
You are also using the key file, it is just being accessed transparently, so there's no real benefit in what they do.
How is it better than the ssh model that we are using?
better is a subjective term, but IMHO it is actually best that explicitly stating the key is not required. Not placing the key in the automatic location would only be preferable if you wanted to use different key pairs and ensure that one isn't used automatically. But even then, for any server I commonly connected to, I would configure ssh to pick the right key file.
Properly configuring ssh to connect make complex setups easy to use, like accessing an internal machine jumping through an intermediate bastion host, or just performing a rsync there (which has no direct
-i parameter to pass to the underlying program†)
† I consider much cleaner to do
rsync file server.com: than
RSYNC_CONNECT_PROG='ssh -i /my/keyfile %H' rsync file server.com:).