ObjID in Page Header
First of all, Paul mentions this about those "Metadata" fields in the blog post:


  Note that I didn’t include the fields starting with Metadata:. That’s because they’re not part of a page header. During SQL Server 2005 development I did some major work rewriting the guts of DBCC PAGE and to save everyone using it from having to do all the system table look-ups to determine what the actual object and index IDs are, I changed DBCC PAGE to do them internally and output the results.


So the "Metadata: ObjectId" field should always match the actual object_id from sys.objects.

The other part of the question was eventually answered in the linked blog post as follows:


  The m_objId is only the actual object ID for system tables with IDs less than 100, and for tables in databases upgraded from SQL Server 2000. For all other tables, the m_objId is part of the allocation unit ID.


So the m_objId will match for system tables (and upgrades from SQL Server 2000).  But for others, he says it's "part of the allocation unit ID."  That's a bit vague.

Running SQL Server 2017 here, I can create a user table with one index page and get the following for those two values from DBCC PAGE:

m_objId (AllocUnitId.idObj) = 178
Metadata: ObjectId = 901578250


I can confirm that 901578250 matches what's in sys.objects object_id for this table.  

So where does 178 come from?

Upon further research, Paul has another post: Inside the Storage Engine: How are allocation unit IDs calculated?

In that, he discusses how the allocation_unit_id (from sys.allocation_units) is calculated from m_objId and another internal id field from the page headers (m_indexId).  

So, essentially, after SQL Server 2000, the m_objId value is just a building block used to calculate the ID for the allocation_unit.  It's internal to the page and doesn't really map to something else (not in the same way that "Metadata: ObjectId" does anyway).