FLUSH TABLES WITH READ LOCK is sufficient. This locks the tables, preventing new writes, and it also makes sure any other writes to tables are flushed to the disk volume for MyISAM tables. For InnoDB tables, some changes may still be in the buffer pool, but those change are also accounted for by the InnoDB redo log, so as you start up the replica those changes will be restored automatically (this is the same as InnoDB crash recovery).
Using SHOW MASTER STATUS during the read lock is necessary because you need those coordinates for your CHANGE MASTER command on the replica. It's basically analogous to a bookmark, so the replica knows where to start reading in the binary log.
It is still important to listen to the advice about long-running queries blocking FLUSH TABLES WITH READ LOCK. Any query, even a read-only SELECT, holds a metadata lock on a table. But FTWRL requires no metadata locks held on any tables, at least briefly. So a long-running SELECT will block FTWRL. You can do an experiment to demonstrate this on a test instance of MySQL:
In one window, create a MyISAM table:
mysql> create table test.m (i int) engine=myisam;
mysql> insert into test.m values (42);
Query it in a way that will last some time:
mysql> select sleep(120) from m;
In a second window, try FTWRL:
mysql> flush tables with read lock;
The FTWRL is waiting for that query to finish, so FTWRL can get its own turn at the metadata lock. If that query takes a long time to finish, FTWRL will still be waiting, and also any other queries will be queued up waiting for FTWRL to release its metadata locks on all tables.
Percona added a feature to their version of MySQL to help in these situations. It's a lock used during backups which does not suffer this blocking behavior. Read https://www.percona.com/blog/2014/03/11/introducing-backup-locks-percona-server-2/ for details if you're interested, but if you use mainstream MySQL, you don't have this feature.
The LVM snapshot method is a pretty good solution given that you have a mix of InnoDB and MyISAM tables, because the lock can be done pretty briefly, just long enough to acquire the LVM snapshot and read the MASTER STATUS.
I'm accustomed to using Percona XtraBackup, which does not require locking, as long as the database stores only InnoDB tables (except for the mysql system tables, which are very small, so they are not a problem to back up during a brief read lock). It's my preference to insist that all tables are stored in the InnoDB. MyISAM has poor performance and is susceptible to data corruption.